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(57) Abstract 


A physician order entry system and method provides cross-checking of prescribed medications against one or more databases to 
determine the propriety of administering a prescribed medication to a patient. The system allows entry of a prescription of medication. 
Once a prescription is entered for a patient, the system checks patient information and/or pharmaceutical information to determine whether 
the prescribed medication is appropriate. If appropriate, the prescription is forwarded to a pharmacy and filled. The medication is then 
delivered to the patient for administration. If it is determined that the prescription is inappropriate, a health care professional, such as for 
example the tending physician or pharmacist is notified of the concern. 
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DESCRIPTIO N 
Health Care gystgm emd Method 

£pr Phygigj-^n Order Entry 

5 Backgrou nd of the Invention 

This invention relates generally to order entry 
systems, and more specifically to a system and method for 
entry of a physician order for a prescription of 
medication. 

10 Although physicians, pharmacists, nurses, care givers 

and other health-care providers strive for error-free 
patient care, they frequently fall short of the mark. 
Often this is due to the complexity of modern medicine and 
the trend to minimize costs of delivery resulting in fewer 

15 and lower paid nurses, pharmacists, technicians and 
hospital employees. Indeed, the frequency of injuries 
from improperly formulated or delivered medication, 
(sometimes referred to as "adverse drug events") is 
rapidly increasing. Reduction of such injuries is an 

2 0 urgent need in light of the following statistic: 

researchers estimate that 180,000 people die in the U.S. 
annually from adverse drug events. That number of deaths 
is the equivalent of 3 jumbo jet crashes every 2 days. 
The severity of the problem is compounded by a general 
25 lack of awareness amongst both clinicians and the general 
public that a problem even exists. L. Leape, Error in 
Medicine Journal of the American Medical Association, 
December 21, 1994, Vol. 272 No. 23, p. 1851. 

Many of these adverse drug events result from errors 

3 0 in administering intravenous .(IV) therapy. During any 

type of extensive hospitalization, a patient typically 
receives some form of intravenous therapy because it is a 
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fast and efficient route for the delivery of needed fluids 
and medications to a patient . The IV thus serves as the 
preferred transport vehicle for the intermittent delivery 
of a drug. 

5 There are at least six basic classes of IV drugs: 

total parenteral nutrition (TPN) ; biotechnology (growth 
hormone for example) ; pain medication; continuous critical 
care medications; chemotherapy; and intermit tents . 
Intermittent IV drugs are typically delivered in 4-6 doses 

10 spread out over a given period, such as a day, although 
other dosing intervals can be encountered. 

Intermittent IV drugs can include, but are not 
limited to, antibiotics, antiemetics, H2 antagonists, 
steroids, and diuretics. IV drugs are typically prepared 

15 by the pharmacy or the manufacturer. Intermittent IV drugs 
represent one of the largest segments of medications 
delivered in a hospital. 

For ease of use, manufacturers of intermittent IV 
drugs typically package the drugs into vials such as 

20 single-dose vials, multiple-dose vials and custom-dose 
vials. A single-dose vial is defined as a vial whose 
entire contents is acceptable or intended for use as a 
single dose to a patient. A multiple dose-vial is defined 
as a vial containing several doses of a drug. A custom 

25 dose vial is defined as a vial containing an amount of 
drug that is not prepackaged in a single or multiple dose 
"unit of use" configuration. The custom-dose vial can be 
used where a patient requires more or less than the 
contents of a single vial. Custom dosing can dictated by 

3 0 factors such as, for example, the patient's body weight, 
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the patient's body surface area, lab results, and other 
factors . 

Although clinicians may administer intermittent IV 
drugs quite often, the single- or multiple-dose vial 
5 configuration is typically not suitable for immediate 
intravenous delivery. This is because such drugs are 
normally packaged in a powdered, lyophilized or 
concentrated liquid form. Therefore, these drugs require 
conversion into a form more suitable for intravenous 

10 delivery. This conversion of intermittent IV drugs into 
a form suitable for intravenous delivery is known as the 
IV admixture process or simply admixture. 

The admixture process normally includes a 
reconstitution step (if the medication is powdered or 

15 lyophilized, for example) and a dilution step. A 
pharmacist or technician ordinarily performs the admixture 
process after receipt of the prescription. This procedure 
is labor intensive and costly as well as fraught with 
potential error. Cohen MR, Davis NM. Medication Errors : 

20 Causes and Prevention . 1981. Schneider PJ, Gift MG. Cost 
of medication-related problems at a university hospital . 
Am J Health-Syst Pharm. 1995; 52:2415-18. Belkin, Who' s 
to Blame? It's the Wrong Question. N.Y. Times Magazine 
1997, p 28 - 

25 Reconstitution, in the case of a lyophilized or 

powdered drug, involves the pharmacist or technician 
injecting a small amount of sterile water or other agent 
into the drug vial and agitating the vial to thoroughly 
dissolve the drug. Repetition of this procedure under 

30 aseptic conditions is difficult. Additionally, constant 
exposure of the technician to drugs, many of which are 
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toxic in concentrated form, represents a hazard to the 
technician ' s health . 

After reconstitution, a few of these drugs are now 
properly prepared for intravenous delivery. However, many 
5 drugs, after reconstitution, are too highly concentrated 
for immediate intravenous delivery. Such a concentrated 
solution could irritate or injure sensitive venous tissue. 
Thus, for most drugs, whether reconstituted or already 
available in concentrated liquid form, they must typically 

10 be diluted to prevent vein or tissue injury. 

Dilution can be performed using a number of different 
techniques. One such technique is carried out by 
reinserting a syringe into the vial containing the 
reconstituted drug and withdrawing the appropriate amount 

15 of drug into the syringe. The contents of the syringe are 
then injected into a container holding a larger volume of 
solution commonly termed "diluent." The amount of 
dilution is a function of the characteristics of the drug, 
dosage, concentration, and can also be based on a 

20 patient's weight or body surface area, as well as other 
factors. The dilution volume of a drug can range from 0 
ml up to a liter, or higher. 

One leading method of dilution involves injecting the 
contents of the syringe containing reconstituted 

25 medication into a flexible plastic bag sometimes known as 
a minibag. The minibag is a single use, sterile package 
containing an appropriate amount (e.g., 50- or 100- mi's) 
of diluent. The drug is typically added to the container 
through an injection port on the minibag. 

3 0 After the drug has been reconstituted and/or diluted, 

the pharmacist or technician affixes a preprinted patient - 
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specific label to the bag. A pharmacist verifies the work 
and signs off on the label. The prepared minibag is then 
placed into refrigerated storage until delivery to the 
patient ' s location . 
5 Despite the verification made by the pharmacist, 

given the number of IV drugs required by a typical 
hospital daily, prescription, admixture and delivery 
errors can still arise. Errors can include, for example: 
improperly mixed drugs, dosages delivered too early, too 

10 late or not all, incorrect dosages ordered by the 
physician, lost tracking and billing, and costly drug 
waste. Indeed, a recent report notes that the observed 
error for compounding I.V. admixtures was 9%. Flynn et 
al . , Observational Study of Accuracy in Compounding I.V. 

15 Admixtur es at Five Hospitals, American Journal of Health 
Systems Pharmacia, Vol. 54, April 15, 1997, p. 904. Cohen 

MR, Davis NM. Confusing and dangerous medical 

Abbreviating tfrfrt should never fre used* Penn Nurse. 19 91 ; 
46(5): 4 -5. Cohen MR, Davis NM. Pharmacy label mix-ups . 

20 Am Pharm. 1992; NS32 (1) : 26-7 . Cohen MR, Davis NM. 
Minimizing look-alike generic mix-ups. Am Pharm. 1994; 
NS34 (3) :22-3 . Cohen MR, Davis NM. More look-alike and 
sound- alike errors . Am Pharm. 1993; NS33(10):32. An 
incorrect drug delivery can result in increased patient 

25 stays and, in some cases, serious injury or death. 
Studies indicate the average hospital spends approximately 
$2.8 million annually due to hospital stays extended 
because of preventable medication errors. Bates DW, The 
Cost of Adverse Pruq Event s in H o s pitalised Patients, jama 

30 Jan. 22/29, 1997; Vol.277 No. 4, 307-311. The national cost 
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of these extended stays is estimated to exceed $4.2 
billion annually. Classen DC, Adverse Drug Events in 
Hospitalized Patients , JAMA Jan. 22/29, 1997; Vol.277 No. 4, 
301-306. 

5 In addition to being labor intensive and error-prone, 

the admixture procedure just described is also wasteful. 
Often, the reconstituted and diluted drug has a short 
shelf life. Even with refrigeration, the solution should 
be discarded after its shelf life has expired, often 

10 within a few days after the admixture process. Thus, if 
a batch is prepared and subsequently not needed, it will 
likely be wasted. 

Furthermore, the use of minibags can lead to fluid 
> overloading of the patient, particularly when multiple 

15 drugs are delivered to the patient intravenously. Because 
multiple drugs usually cannot be diluted simultaneously 
within the same minibag due to incompatibility potentials, 
each drug. is diluted in its own minibag. This compounds 
the fluid overloading problem. 

20 Alternatives to the labor-intensive IV admixture 

process just described have undesirable properties as 
well . Convenience packaging systems represent an 

alternative falling into two major categories. The first 
is premix or frozen premix which is a manufacturer 

25 prepackaged drug that is stable when diluted or when 
diluted and frozen. This method still suffers from the 
fluid overloading problem discussed earlier. Also, even 
though the drug stability is extended, there is still a 
limited shelf life. Additionally, this method suffers 

30 from the fact that manufacturers form strategic alliances 
with specific pharmaceutical companies and package that 
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company's "brand name" drug with their minibag, charging 
a premium in the process. This prevents a hospital from 
using the cheaper generic form of the drug should the use 
of a premixed minibag be desirable. 
5 A second alternative are minibags with vial adapters. 

A unit dose vial is attached to the minibag' s vial adapter 
and the vial adapter's seal is then broken. The nurse 
reconstitutes and simultaneously dilutes the drug by 
moving fluid from the minibag into the vial. This 

10 category of minibags suffers from high cost, reduced 
ability to utilize generic drug substitutes, fluid 
overloading and the potential for drug waste. In 
addition, because nurses are not trained as pharmacists, 
the potential for errors are compounded when the pharmacy 

15 does not control the admixture process and nurses perform 
the so-called "mix and match" on the floor of the 
hospital . 

Referring now to Figure 1, we illustrate the multiple 
labor intensive and costly steps which must be carried out 

20 for the prior art manual IV admixture process. After a 
diagnosis 1, an order is written by the medical doctor 2. 
A pharmacist reviews the order 3, and approves and enters 
the prescription date 4. Prior to procuring the necessary 
materials 6, the pharmacist generates a pharmacy pick list 

25 of the required items 5. Typically a pharmacy technician 
then reconstitutes the drug 7 and dilutes the 
reconstituted medication into a minibag or other container 
8 . Then the pharmacist checks the work of the 

technician, initials and places a label on the minibag 9 

30 before the minibag is stored for delivery 10. Steps 3 
through 10 represent the pharmacy admixture process 11. 
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The minibags are thereafter distributed for delivery 
to the patient. Typically, the minibags are delivered to 
nursing stations in the general patient area 12 of the 
hospital. The nurse or other clinician reads the 
5 patient's prescription and acquires the medication 13 from 
the administration station. The clinician checks and 
verifies that particular medications are correlated with 
particular patients as per the prescription 14. The 
medications are then infused into the patient 15. The 
10 final step is the logging of the dose delivery and time, 
denoted as "manual information capture" 16. Steps 12 
through 16 represent the administration of medication 
process 17. 

In a effort to avoid the problems associated with the 

15 labor-intensive prior art IV admixture process, machine- 
aided reconstitution systems have been implemented. For 
example, various embodiments of a reconstitution and 
delivery system are disclosed in U.S. Pat. No. 4,410,321; 
U.S. Pat. No. 4,411,662; U.S. Pat. No. 4,432,755; and U.S. 

20 Pat. No. 4,458,733. The systems disclosed by these 
patents , however, require that a number of operations be 
manually performed by the operator before infusion of the 
reconstituted medication can be performed. A automated 
system for reconstituting a drug and delivering the drug 

25 intravenously is disclosed in U.S. Pat. No. 5,116,316. 
Among other potential shortcomings, none of these 
conventional systems address the problem of preventing 
medication errors by verifying patient's prescription and 
drug dosage in the crucial gap between the preparation of 

30 the drug through the admixture process and its 
administration and delivery to a patient. 
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Whether a drug is manually reconstituted and/or 
diluted through a manual admixture process or by machine 
as described in the above patents, the prepared IV drug is 
delivered into the veins of the patient at bedside. One 
5 conventional technique for delivery of the prepared IV 
drug is for a clinician to use a syringe and simply inject 
the prepared drug directly into a vein. However, to 
prevent vein irritation, in some instances it is necessary 
for the clinician to take several minutes to slowly inject 
10 the contents of the syringe into the vein. Moreover, many 
drugs require larger dilution volumes and longer delivery 
times than can be practically provided for by manual use 
of a syringe . 

Another conventional technique for delivery of a 

15 prepared IV drug is through the use of a syringe pump. For 
such pumps, a pharmacist selects the appropriate size 
syringe, fills it, applies a label, attaches a specialized 
IV set, and delivers this to the clinician. The clinician 
loads the syringe into a syringe pump and starts the 

20 system. The syringe pump delivery system suffers from the 
costs associated with the labor required by the pharmacist 
in preparing the syringe and also does not have 
verification and recording features. 

One of the most popular conventional mechanized 

25 delivery systems is the peristaltic infusion pump which 
operates by squeezing the delivery line to force the 
prepared drug into a vein of the patient. Such a delivery 
system is illustrated in Figure 2. The system 32 includes 
three bags 36, 38, and 39, and a bottle or hard containers 

3 0 40, each of which contains a fluid to be delivered to the 
patient. The containers are coupled by flexible fluid 
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flow conduits or tubes 42, 44, 46, and 48, the end of 
which are coupled to catheters or similar devices for 
delivering fluid to the patient. Each of the flow lines 
42 and 44 includes a conventional peristaltic infusion 
5 pump 50 which may be adjusted to deliver a specific 
volumetric flow to the patient. 

Peristaltic pumps exert a great deal of force on the 
IV line to effectuate pumping. After repeated squeezing, 
the line loses its round shape, becoming oblong from the 

10 pinching force of the peristaltic pump. Such a misshapen 
line may restrict flow. Thus some peristaltic pumps 
cannot deliver precise amounts of fluid due to this line 
distortion phenomenon. Finally, these pumps cannot control 
air within the line. Although these pumps may have air- 

15 in-line sensors at the output of the pump, these pumps 
cannot detect bubbles at points upstream of the pump 
outlet and circulate them in a way so as to avoid air 
being pumped into the pump outlet altogether. The 
resulting air bubble alarms are a constant nuisance for 

20 nursing staff, especially considering that most of the 
detected bubbles are medically insignificant. 

Finally, hospital information systems are frequently 
less than adequate. Because pharmacists are overworked, 
they make mistakes and approve orders which they should 

25 not have. For example, they may approve: a prescription 
for a patient with known allergies to the prescribed drug; 
a prescription to a patient already receiving a different 
drug which is incompatible with the additional prescribed 
drug; a drug inappropriate to the patient's diagnosis, an 

3 0 inappropriate amount of a drug when lab values indicate 
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new dosage levels. These mistakes are created by a lack 
of an integrated information system. 


Summary of Invention 
5 The present invention is directed toward a system and 

method for handling prescription information for one or 
more patients. According to the invention, a physician or 
other health care provider enters prescription information 
regarding medication prescribed for a patient. The system 

10 checks one or more databases to determine whether, under 
the circumstances, it is appropriate to administer the 
prescribed medication to the patient. 

If appropriate, the prescription is forwarded to a 
pharmacy where it is filled, and the medication is 

15 provided for administration to the patient. If there are 
indications that the prescription may be inappropriate as 
prescribed or inappropriate for administration to the 
patient, the system provides a warning of this condition. 
The system can check patient databases as well as 

20 pharmaceutical databases to determine whether the 
prescription is appropriate and whether the prescribed 
medication is appropriate . for administration to the 
patient. For example, the system may check items in a 
patient database such as patient allergies, patient 

25 condition, patient demographics, medications already 
prescribed for the patient, and other patient information 
to determine whether there is any indication that the 
prescribed medication may be inappropriate for the 
patient . 

30 The system may also check medication information such 

as, for example, parametric limits for the prescribed 
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medication to determine whether the prescription is 
appropriate independent of the patient for whom the 
medication was prescribed. One example of a parametric 
limit may be maximum and minimum dosage levels. In this 
5 example, if the prescribed dosage is outside of the 
established range, the prescription may be determined to 
be inappropriate . 

If there is information indicating that the 
prescription may not be appropriate for the patient, the 

10 system generates a warning. For example, the system may 
determine that the dosage level is too high for the 
prescribed medication or for the particular patient based 
on his or her condition; or that the patient is allergic 
to the medication, has a condition which may be aggravated 

15 by the medication, or has already been prescribed a 
medication to treat the diagnosed condition. In these or 
other circumstances which may render a prescription 
actually or potentially inappropriate, it may be advisable 
to reconsider administering the prescribed medication to 

2 0 the patient. Therefore, an indication of the 

inappropriateness is given, allowing the physician or 
other health care professional to further investigate the 
situation before the medication is administered. 

Where it is determined that the prescribed medication 

25 is inappropriate, the system may provide an appropriate 
indication. For example, the system may inhibit the 
forwarding of the prescription to the pharmacy, or may 
forward the prescription, but instruct the pharmacy not to 
fill or deliver the medication without further 

30 authorization. Alternatively, the system may provide the 
prescription, but simply warn an appropriate health care 
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professional that the situation should be investigated. 
The system may also provide a message to the prescribing 
physician that the prescription is inappropriate, and may 
provide the reason for this conclusion. Such a message can 
5 be provided in the form of a message on a display screen, 
a print out from a printer, via a synthesized voice or by 
other messaging means. 

The system may be configured to allow a health care 
professional, such as the tending physician for example, 

10 to override the warning that a prescription may be 
appropriate and allow the prescription to be filled and 
administered. This course of action may be followed by 
the physician, for example, where he or she is aware of 
the concern but deems the downside risk or potential harm 

15 to be outweighed by the necessity or benefits of the 
prescribed medication. 

The order entry terminal can be a fully integrated 
stand-alone terminal capable of accepting prescriptions, 
checking the appropriate databases, forwarding 

2 0 prescriptions to a pharmacy and generating desired reports 

and printouts. Such a terminal can be stationary, such as, 
for example, implemented using a desktop computer with the 
appropriate peripherals and software. Alternatively, the 
terminal could be a portable terminal capable of being 
25 transported from location to location. The portable 
terminal can even be. implemented as a hand-held terminal 
capable of being easily carried with a physician on his or 
her rounds. 

The order entry system can also be a more distributed 

3 0 system, having components provided at one or more 

locations. For example, there may be prescription entry 
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terminals (portable or stationary) which interface with 
external databases for patient and/or medication 
information and which also interface with other entities 
or facilities in a health care environment for the 
5 decision making and order filling processes. Where 
external databases are used, any or all of the required 
data may still be maintained locally, depending on, for 
example, a tradeoff between memory requirements and access 
speed requirements . 

10 The invention can also provide data and analysis to 

assist the health care professional, such as the tending 
physician for example, in determining a suitable 
medication to prescribe for the patient . In this aspect 
of the invention, an analysis package is provided which 

15 considers patient information from the database as well as 
information pertaining to the medications available in a 
designated pharmacy to suggest to the physician which 
medications may be appropriate to administer to the 
patient, and at what dosage levels and intervals. 

20 According to this analysis feature, the system 

accepts the diagnosis of the patient as entered by the 
physician and checks the pharmaceutical database to 
determine which medications are appropriate to treat the 
diagnosed condition. Pharmaceutical information, such as 

25 for example that available in the IV template, is used to 
suggest recommended dosage levels and intervals to the 
physician for the suggested medications. In some 
environments, certain drugs may only be available in 
certain dosages. Therefore, in this environment, the 

3 0 analysis package can provide the physician with a list of 
possible medications and available dosages . 
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The prescription analysis feature may also use other 
patient information to assist in the decision making 
process, such as, for example, patient allergies, patient 
demographics, lab test values, other patient medications, 
5 or other patient information provided in the patient 
database or entered by the physician. 

The analysis package may rule out certain medications 
or highlight other medications based on this additional 
patient information. The analysis package may also 

10 recommend specific dosage levels based on the patient 
information. According to another aspect of the analysis 
package, the system may prompt the physician to enter 
additional information to aid in the decision making 
process. For example, consider a scenario where the 

15 patient's weight is not available in the patient database 
and this information is desired to accurately determine 
the dosage level. The system may ask the physician to 
enter the patient's weight into the system. Ideally, 
however, all of the patient's key information is already 

20 entered into the system or otherwise available from a 
database . 

Brief pegcrj.pt ion the py^ingg 

Figure 1 is a flow chart illustrating a manual 
25 admixture and delivery process. 

Figure 2 is a perspective view of a conventional 
peristaltic infusion pump used to deliver IV solution to 
a patient. 

Figure 3 is a diagram generally illustrating an 
30 automated medication management system according to one 
embodiment of the invention. 
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Figure 4 is an operational flow diagram illustrating 
a method by which a patient treatment process performed 
according to one embodiment of the automated medication 
management system . 
. 5 , Figures 5 A and 5B are perspective diagrams of an 

automated medication management system according to one 
embodiment of the invention. 

Figure 6 is a flow diagram indicating the steps which 
are utilized for data entry compounding, confirmation of 
10 the identity of patient, and drug and recording and 
monitoring drug usage and delivery according to one 
embodiment of the invention. 

Figure 7 is an exploded view of the automated 
medication management system according to one embodiment 
15 of the invention. 

Figure 8 is a detailed illustration of an example 
implementation of a cassette with vials mounted thereon 
according to one embodiment . 

Figure 9 is a diagram illustrating a vial mounted to 
20 a cassette spike according to one embodiment. 

Figure 10 is a cross-sectional view of a spike with 
a cap mounted thereon. 

Figure 11 is a diagram illustrating a downward view 
of how a cassette mounts on unit 75 according to one 
25 embodiment. 

Figure 12 is a diagram illustrating the vial loading 
mechanism according to one embodiment. 

Figure 13 is a diagram illustrating the vial loading 
mechanism according to one embodiment. 
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Figure 14 is a diagram illustrating an example user 
interface for an automated medication management system 
according to one embodiment of the invention. 

Figure 15 is a diagram illustrating a perspective 
5 view of a cassette and a mounting structure for the 
cassette according to one embodiment of the invention. 

Figure 16 is a block diagram illustrating an example 
architecture for an implementation of automated medication 
management system according to one embodiment . 
10 Figure 17 is a diagram illustrating an example 

implementation of an automated health care facility 
according to one embodiment . 

Figure 18 is a diagram illustrating an example 
architecture for a data entry terminal according to one 
15 embodiment . 

Figure 19 is a diagram illustrating an example 
hardware and/or software implementation of elements of the 
invention according to one embodiment. 

Figure 20 is a flow chart illustrating a system 
20 start-up overview according to one embodiment of the 
invention. 

Figure 21 is a flow chart illustrating a patient 
Identification routine according to one embodiment of the 
invention. 

25 Figure 22 is a flow chart illustrating a clinician ID 

routine according to one embodiment of the invention. 

Figure 23 is a flow chart illustrating a cassette 
loading and priming routine according to one embodiment of 
the invention. 
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Figure 24 is a flow chart illustrating a vial 
attachment routine according to one embodiment of the 
invention . 

Figures 25, 26, 27, and 28 are a flow chart 
5 illustrating a non-IV programming routine according to one 
embodiment of the invention. 

Figure 2 9 is a flow chart illustrating door open 
request routine according to one embodiment of the 
invention. 

10 Figure 3 0 is a flow chart illustrating a hold 

delivery routine according to one embodiment of the 
invention 

Figure 31 is a flow chart illustrating a primary IV 
setup according to one embodiment of the invention. 
15 Figures 32A and 32B are a flow chart illustrating a 

vial port programming routine according to one embodiment 
of the invention. 

Figure 33 is a flow chart illustrating a drug to 
diluent incompatibility and special diluent requirement 
20 routine according to one embodiment of the invention. 

Figure 34 is a flow chart illustrating a network 
routine according to one embodiment of the invention. 

Figures 3 5A, 35B, and 35C are a flow chart 
illustrating a luer port programming routine according to 
25 one embodiment of the invention. 

Description of the Preferred Embodiments 

The present invention is directed toward an automated 
physician order entry system. The order entry system and 
3 0 method according to the invention provides a means by 
which a physician or other appropriate health- care 
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provider can enter prescription information for a patient. 
This prescription information is checked against 
information contained in one or more databases to 
determine the propriety of providing the prescribed 
5 medication to the patient. 

In one embodiment, the order entry device can be a 
portable or stationary terminal at which the prescription 
is entered. The order entry device can communicate with 
other services such as, for example, a pharmacy for 

10 automated delivery of the prescription to the pharmacy. 
In another embodiment, the device can also communicate 
with an automated medication management system to provide 
information relevant to the infusion of IV medication as 
well as provide automated updates to patient and health 

15 care facility records and automated cross-checking for 
propriety of administration of the medication. 

Automated Medication Management System 

Figure 3 is a diagram generally illustrating an 

20 automated medication management system 3 00 according to 
one embodiment of the invention. Referring now to FIG. 3, 
the automated medication management system in this 
embodiment includes a control and management module 304, 
and a preparation and delivery module 308. The automated 

25 medication management system 300 can also include a data 
entry device 312 and internal data storage 316. 
Additionally, a communications interface 32 0 can be 
provided for communication to external entities such as, 
for example, an external database 332, an external server 

30 (not illustrated), or other remote or external device (s), 
networks, or entities. 
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In the illustrated embodiment, preparation and 
delivery module 308 includes fluid delivery module 8 8 and 
cassette 77. Preparation and delivery module 308 provides 
automated reconstitution and dilution of medications, 
5 where required or appropriate. In one embodiment, 
cassette 77 incorporates one or more pressure conduction 
chambers, which are operated on by positive and negative 
pneumatic pressure supplied by fluid delivery module 88 to 
perform reconstitution, dilution and metering of the 
. 10 medication. Fluid delivery module 88 is controlled by 
control and management module 304. 

Control and management module 304 determines the 
appropriate admixture process to be followed for the 
subject medication and controls fluid delivery module 88 

15 to reconstitute and/or dilute the medication as 
determined. Control and management module 3 04 also 
controls delivery of the medication to the patient. 

Control and management module 3 04 can receive data to 
dete rmine the appropriate admixture process from one or 

20 more sources. These sources can include, for example, 
data entry module 312, external sources via communications 
interface 320 and internal data storage 316. Control and 
management module 304 can also use data from such sources 
to determine the appropriateness of the medication to be 

25 delivered to the particular patient. 

Data entry device 312 can comprise one or more 
devices for inputting data such as, for example, a bar 
code reader, a keypad or keyboard, a touch- screen display, 
a magnetic card reader or other data entry device. The 

3 0 data entered using data entry device 312 can include, for 
example, patient data, medication data, clinician 
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identification and other pertinent or related data. 
Entered data can be used for control and management of the 
delivery system and stored for later recall. 

In one embodiment, data entry device 312 includes a 
5 bar code reader which can be used to scan bar codes on the 
medication to be administered to the patient. The bar 
code reader can also be used to scan bar codes indicating 
information such as, for example, patient ID'S or other 
patient information from the patient's chart, wristband or 

10 other source; the clinician's ID (e.g., from an ID is 
encoded on a badge) and other information. In one 
embodiment, the combination of a bar code reader and a 
keyboard, for example, allows entry of scanned and 
manually entered data. 

15 Internal data storage 316 can comprise one or more 

data storage devices for internally storing pertinent 
information. In one embodiment a medication 

administration record is stored internally for later 
retrieval or download. In another embodiment, an internal 

2 0 database can be included for storing information such as 

patient information, medication information and other 
pertinent information . 

Communication interface 320 can be used to 
communicate with' external devices such as, for example, 
25 external databases, servers, controllers, or other 
entities. In one embodiment, communication interface is 
a network interface for connection to, among other network 
entities, a network database comprising information such 
as medication information, pharmacy information, patient 

3 0 information and other information. 
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In one embodiment, the system cross checks the 
medication to be administered against data contained in 
one or more databases to provide a safeguard against 
administration of improper medications or at improper 
5 dosage levels. In this embodiment, control and management 
module 304 checks the intended medication against 
information in the one or more databases and enables 
delivery only after verification that the particular 
patient is to receive a prescribed drug in the correct 

10 amount, with the proper diluent if required, at the proper 
time. Because this system provides a safety check before 
delivery of a drug, errors in delivering the incorrect 
drug or the incorrect amount are reduced. 

Such a safety check can be performed any time after 

15 the prescription is entered and ideally, before the 
prescribed medication is administered to the patient . For 
example, the check can be performed at the time of 
prescription entry, before the prescription is prepared by 
the pharmacy, or before administration of the medication 

20 to the patient. 

Having generally described an example architecture of 
the automated medication management system 300, its 
operation is now described in an example environment. The 
automated medication management system, according to the 

25 present invention, is suitable for use in numerous 
environments in which medications are delivered to a 
patient. Embodiments of the invention are now described 
in terms of one such environment. This description is 
provided to facilitate discussion of the invention in an 

3 0 example operational environment and is not intended to 
limit the invention to application in such an environment. 
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In fact, after reading this description, it will become 
apparent to one skilled in the how to implement the 
invention in numerous alternative environments. 

Figure 4 is an operational flow diagram illustrating 
5 the operation of automated medication management system 
3 00 in an example environment. In a step 4 04, a patient 
is evaluated by a health care professional such as, for 
example, a physician. The health care professional 
determines whether any medication is required or 

10 recommended to treat the patient's condition. If so, the 
appropriate medication, dosage and dosing interval are 
determined for that patient. In one embodiment, the 
physician can access a prescription analysis package that 
aids in the selection of the appropriate medication. This 

15 clinical decision-making database can be used to check 
diagnosis, patient demographics, known allergies, and 
current lab values to assist the physician in selecting 
the optimal medication. 

In a step 408, after the health care professional 

2 0 determines which medication is appropriate to treat the 
patient's condition, a prescription is generated by that 
health care professional. The prescription is then 
delivered to and filled by a pharmacy, such as, for 
example, the hospital pharmacy. In one embodiment, the 

25 prescription is hand carried by a clinician or delivered 
by other manual means to the pharmacy so that it can be 
filled. 

In an alternative embodiment, the physician order for 
the prescription can be entered into the data entry 
30 terminal and the prescription can then be electronically 
or otherwise automatically delivered to the pharmacy such 
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as, for example, by electronic mail or by other electronic 
means. In yet another embodiment, the prescription can be 
entered using data entry device 312. The prescription can 
then be transferred to the pharmacy or other entity 
5 electronically via communications interface 320. 

In an embodiment where the prescription information 
is entered electronically and stored in a database, the 
physician order can be automatically distributed to the 
pharmacy as it is entered into the database. 

,10 Alternatively, the prescription can be subsequently 
retrieved from the database and sent to the pharmacy 
either automatically or by a health care professional. In 
other words, through the use of networking or other 
communication techniques, the delivery of the prescription 

15 to the pharmacy can be fully or partially automated. 

Upon entry of a prescription, or prior to filling the 
prescription, the prescription information can be checked 
against one or more databases to determine the propriety 
of the prescription. If it is determined that the 

20 prescription as written or entered into the system may be 
inappropriate, steps are taken to warn of the error and 
allow the prescription to be verified or altered before 
administration of the prescribed medication. This process 
is described in greater detail below with reference to 

25 several embodiments. 

In a step 412, pertinent patient data useful for the 
administration of the medication is entered into the 
automated medication management system 300. In one 
embodiment the information is stored in a patient 

30 database, and can be downloaded from the patient database 
to automated delivery system 300. This too can be done by 
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a hard-wired or a wireless communication link. In one 
embodiment, the patient database or a duplicate copy- 
thereof is resident in automated medication management 
system 3 00, allowing direct access of patient data. 
5 In one embodiment, the identification of the patient 

is entered into automated delivery system 300, and this 
identification is used to retrieve one or more data 
records from the one or more databases. The patient data 
can be entered by the clinician using data entry device 

10 312. Where data entry device 312 is a keypad, touch- 
screen display, keyboard, or other terminal -like device, 
the information is simply manually entered by the 
clinician. Where data entry device 312 includes an 
automated code reader such as a bar code scanner or 

15 magnetic reader or other code- or data-reading device, 
pertinent patient information can be scanned in using bar 
codes, magnetic stripes, voice recognition or other coded 
materials . 

In one embodiment, the patient data entered into the 
2 0 automated medication management system 3 00 can include 
patient identification as well as other information 
pertaining to the patient. 

In order to identify the health care professional to 
automated medication management system 3 00, his or her ID 
25 (identification) can also be entered. The ID can be a 
name, employee number or other identifying code or 
designation. In one embodiment, the ID can be entered by 
using a bar code or magnetic scanner to . scan an 
identifying code provided by the health care professional. 
30 Such a code can be provided, for example, on the health 
care professional's badge. Additional security can be 
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provided by requiring the health care professional to 
enter a PIN (personal identification number) or other 
password associated with his or her ID. Additionally, 
manual entry of ID and PIN can be provided by keypad or 
5 touch screen display. Alternative data entry means can 
also be utilized for identification. 

In a step 416, the prescribed medication which has 
been received from the pharmacy is loaded into automated 
medication management system 300. This medication may be 

10 unprepared in that it requires reconstitution and/or 
dilution before it can be administered to the patient. 

The automated delivery system can access information 
in a pharmaceutical database to determine whether 
reconstitution and/or dilution are required for each of 

15 the medications entered as well as the rate of delivery 
for the prepared medications. In one embodiment, control 
and management system 304 determines the proper admixture 
process and controls preparation and delivery module 3 08 
for the admixture and infusion of the prescribed 

20 medications. Control and management system 304 may 
utilize internally or externally stored information such 
as, for example, IV templates to determine the correct 
reconstitution and dilution levels. 

For example, control and management system 3 04 can 

25 look up a prescribed medication in a pharmaceutical or 
other database and determine from the database the 
appropriate reconstitution and dilution levels. 
Alternatively, this information can be dictated by the 
prescription and either manually entered or automatically 

3 0 downloaded to the automated medication management system 
300. 
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In one embodiment, the medication information can be 
entered by data entry module 312 such as by the operator 
keying in the identification information or utilizing a 
bar code scanner or other code reader to read a bar code 
5 label on the medication container. The scanner can be a 
hand-held scanner connected to automated medication 
management system 3 00 via a wired or wireless interface. 

In another embodiment, a bar code scanner or other 
code reader is integrated into the system such that the 

10 bar code label or other coded information is read from the 
medication vial when the vial is loaded into the system. 
As would be apparent to one of ordinary skill in the art 
after reading this description, other data entry 
techniques can be used as well. 

15 The manner in which medicine is loaded into automated 

medication management system 300 is described in detail 
below. As described below, safeguards are provided to 
ensure that the chances of accidental exposure of the 
medication to the health care professional are minimized. 

2 0 Various safeguards are provided to ensure that the 

appropriate medications are being loaded into the 
automated medication management system 300. In one 
embodiment, the clinician enters an identification of the 
medication into automated medication management system 300 
25 and automated medication management system 3 00 verifies 
that this is the correct medication as prescribed to the 
patient by looking into the patient's database, or into a 
prescription database for example. 

Automated medication management system 3 00 can also 

3 0 check various prescription, medication and patient 

information to ensure that the proper medication is being 
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administered to the proper patient and at the correct 
dosage, and dosing interval. 

For example, automated medication management system 
3 00 can check the patient database to determine whether 
5 the prescribed medications conflict with any information 
in the patient database such as patient allergies, patient 
conditions, patient demographic information, or other 
information which would indicate an actual or possible 
incompatibility with the prescribed medication; current 

10 patient drugs which may be incompatible with the 
prescribed medication; whether the patient has already 
been prescribed medication to treat the condition to 
perform duplicate therapy checking; or other concerns 
which may be raised as a result of the prescription of the 

15 medication to the patient based on the stored information. 
If a concern or incompatibility does exist, a flag can be 
raised to the clinician via a warning sound, indicator 
light, message, or other display or indication on the 
automated medication management system or by a 

2 0 transmission of a message or signal to an appropriate 
location. 

Automated medication management system 300 can also 
check a pharmaceutical database which contains information 
pertaining to the various medications. The pharmaceutical 

25 database can include one or more databases with 
information regarding drug interaction precautions and 
other drug incompatibility problems, as well as drug 
parameters, and IV template information. The information 
in this database can be stored locally in the automated 

30 medication management system 300 (either as original data 
or a duplicate copy) , or stored remotely and accessed by 
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automated medication management system 3 00 prior to 
administration of medication. 

As an example of a check which may occur consider a 
scenario in which a patient suffers from high blood 
5 pressure. As is well known, there are certain medications 
which may further aggravate or compound the high blood 
pressure problem. If such a medication is prescribed for 
the patient, control and management system 3 04 can check 
the medication against known conditions which the 
10 medication may aggravate, determine from the patient 
database whether the patient suffers from any of these 
conditions, and, if so, raise an appropriate flag or 
warning . 

In another example, other information such as either 

15 the dose or dosing interval of the medication or feedback 
on a patient's condition from a laboratory can be checked 
against the patient's age, weight, physical condition, or 
other factors to determine whether the prescription is 
within acceptable bounds. As such, a more fail-safe 

20 mechanism is provided as a cross check against the 
prescription of medication which may not be ideally suited 
to the particular patient given his or her condition. 

This error-checking process can be similar to, or 
even duplicative of, the error checking process described 

25 below with reference to a physician order entry of the 
original prescription. One feature added at this stage, 
however, is the ability to verify the identification of 
the patient to whom the medication is actually going to be 
administered just prior to administration. 

30 In one- embodiment, delivery of the medication is not 

allowed to proceed if the error- checking process 
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determines that it may be inappropriate to administer the 
medication as prescribed. In one embodiment, the halted 
system can be overridden by a health care professional 
with the appropriate authorization clearance level. 
5 In one embodiment, if a warning flag is raised or the 

system halted, the condition can be overridden by the 
appropriate health care professional where that 
professional deems that the prescribed medication is 
appropriate under the circumstances despite the warning. 

10 For example, the physician prescribing the medication may 
note that it does aggravate a condition such as high blood 
pressure but may decide that the patient ' s need for the 
medication outweighs the risk in administering the 
medication and may therefore consider that the prescribed 

15 medication is still appropriate. In this situation, the 
physician simply overrides the alarm and allows the 
delivery to proceed. In one embodiment, the physician may 
do a preemptive override at the time of making the 
physician order in advance of receiving the actual 

20 warning. This override can be stored in the database so. 
that the alarm is avoided. Additionally, occurrences of 
alarms and overridden alarms can be recorded for 
historical and statistical purposes. 

In one embodiment, multiple levels of authorization 

25 are accommodated. Thus, different users may have 
different levels of "clearance" to perform operations such 
as prescribe medication, override alarms, administer 
medication, or perform other operations. For example, a 
user ID or other code may be required for the health care 

30 professional to operate the automated delivery system as 
well as a password or PIN. Different users can be 
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provided with different levels of security, authorization, 
or access. For example, in this environment, a physician 
may be provided with the ability to enter a prescription 
and override a drug warning, whereas a nurse or other 
5 clinician may not. As would be apparent to one of 
ordinary skill in the art after reading this description, 
differing levels of hierarchy and various authorization 
levels can be provided based on the goals of the 
administration of the delivery system and the composure of 

10 the infrastructure in which it is implemented. 

In a step 420, the medication is prepared for the 
patient. In this step, where reconstitution and/or 
dilution are required, preparation and delivery system 3 08 
performs these operations. In one embodiment, as 

15 described below, the admixture process takes place in 
cassette 77 where the medications are properly 
reconstituted and/or diluted as required. 

As discussed above, control of the admixture process 
is undertaken by control and management system 3 04 to 

20 ensure proper admixture is performed. Additional details 
on the manner in which the admixture process is performed 
according to one or more embodiments are provided below. 

In a step 424, the prepared medication is delivered 
to the patient by preparation and delivery unit 308. The 

25 medication is properly metered such that the patient 
receives the correct dose over the defined period of time. 
The system can be set to provide alarms when air is 
present in the delivery lines. 

In a step 428, one or more databases are updated to 

30 indicate that the patient has been administered the 
medication. This information can include information such 
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as the medication administered, the dose administered, the 
date and time on which the medication was administered, 
and other important information. In one embodiment, this 
data is stored in an internal database (e.g., data storage 
5 316) which can then be downloaded to an external database 
for record-keeping or archival purposes. In this 
embodiment, the internal database can be used as a history 
log recording a medication administration record performed 
by automated medication management system 300 over a 

10 period of time. 

Thus, automated medication management system 30 0 can 
be transported from patient to patient for delivery of 
medication and keep an internal log of the deliveries and 
surrounding information. The information stored in the 

15 history log can be printed or displayed to provide health 
care professionals with information regarding recent 
transactions . 

In alternative embodiments, the automated medication 
management system 3 00 can be more permanently connected or 

20 networked to an external database such that an internal 
log need not be kept to update patient, hospital, 
medication, or other records. Information from automated 
medication management system 30 0 can also be provided to 
accounting and other departments for billing, inventory, 

25 statistics collection, or other record-keeping purposes. 

Sample Implementation of Automated M e dication Manaafimpnt- 
System 300 

An example implementation of automated medication 
3 0 management system 3 00 is now described with reference to 
Figures 5A and 5B. After reading this description, it 
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will become apparent to one skilled in the art how to 
implement automated medication management system 3 00 
utilizing alternative configurations. A detailed view of 
a bedside control and delivery unit 50 is shown in Figures 
5 5A and 5B according to one embodiment. . The Bedside 
control and delivery unit 50 includes a head unit 75 
mounted on a base plate 77. The base plate 77 rests on 
the base assembly 76. Base assembly 76 includes side 
doors 80 which pivot open to reveal shelves 81, useful for 

10 storing medical paraphernalia. Also attached to base 
assembly 76 are IV poles 72 and a caster base 82. 
Ambulation bar 73 attaches to base assembly 76 through 
supports 83 . The combination of caster base 82 and 
ambulation bar 73 allow stable patient ambulation. 

15 Head unit 75 includes cassette 77 through which 

fluids and air are transported by fluid delivery module 88 
(not shown) . Cassette 77 is preferably disposable and not 
re-used for other patients or for delivery of subsequent 
medications to the same patient. Vial loading spikes 118 

20 are disposed along the top of cassette 77. When cassette 

77 is mounted in unit 75, drug vials 85 may be pierced by 
spikes 118 so that fluid from within cassette 77 may be 
forced into vials 85 to reconstitute the drug contained 
therein. Hinged door 86 covers vials 85 in ordinary use. 

25 

A clinician mounts cassette 77 by opening outer door 

78 and inner door 87 (not shown) and positioning cassette 
77 against fluid delivery module 88. The clinician then 
closes inner door 87 and outer door 78. In one 

30 embodiment, inner door 87 provides the necessary force to 
keep cassette 77 stationary against fluid delivery module 
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8 8 so that fluid delivery module 88 may pneumatically 
operate cassette 77. Outer door 78 serves as a safety 
check because if inner door 87 is opened, cassette 77 is 
disabled or otherwise prevented- from contacting other 
5 patients. After inner door 87 is opened, fluids in 
cassette 77 could commingle and flow to the patient which 
can be hazardous. A disablement is provided to prevent 
this condition. Because cassette 77 is disabled once 
inner door 87 opens, a warning is displayed to the 
. 10 operator when outer door 78 is opened to prevent 
unnecessary disablement. 

Bar code reader 70 or other data entry device can be 
used to scan the bar codes or other coded label on vials 
85 , pharmacy-prepared labels , manufacturer-prepared 

15 labels, and can also scan coded patient, physician and 
clinician identification. After the clinician enters or 
scans this inf ormation, unit 75 accesses drug database 92 
which can be internal or an external database. Bedside 
control and delivery unit 50 verifies that the particular 

2 0 patient has been prescribed the particular drug being 
administered and that the diluent and additives in bag 89 
are proper by accessing stored information such as, for 
example a patient . profile contained in the patient 
database and the medication information stored in a 

25 pharmaceutical database. In addition, Bedside control and 
delivery unit 50 provides an alarm for dosages which 
exceed safe levels to be delivered by Bedside control and 
delivery unit 50. 

Referring now to Figure 5b, a 'back view of unit 75 is 

30 illustrated. Because in this embodiment Bedside control 
and delivery unit 50 contains a substantial amount of 
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electrical and electro-mechanical hardware, a means for 
dissipating heat resulting from this hardware is provided. 
Because a fan could result in noise bothersome to 
patients, one embodiment of Bedside control and delivery 
5 unit 50 employs a large heat sink 91 instead. Other heat 
dissipation means can be used. 

Also shown in Figure 5b, a printer 90 can be utilized 
to print records of medications delivered to the patient. 
Rather than requiring a clinician to manually keep records 

10 of administered medications, in one embodiment as 
described above, Bedside control and delivery unit 50 
records all drug events and can then print those events on 
printer 90 or download them to a database. Alternatively, 
the system can access a remote printer at the nurse's 

15 station via a network connection. In one embodiment, a 
caster base 82 or other rollers are provided to facilitate 
ambulation of the system. 

Figure 6 is a block diagram generally illustrating 
the use of automated medication management system 3 00 for 

2 0 administering medication to a patient in the embodiment 
described in Figures 5A and 5B. To begin the process, in 
a step 94, the system is brought to the patient's bedside. 
A cassette 77 is loaded if IV delivery is required. In 
one embodiment, a network connection is established by 

25 powering up the system. 

In a step 95, The patient's identification is scanned 
through the use of scanner 70, so that the system can be 
set up to support the specific patient and can check that 
the medication is actually prescribed for the identified 

30 patient. At step 96, the clinician's identification can 
be scanned as well and his or her password entered. This 
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acts as a security measure, to help prevent unauthorized 
personnel from altering drug delivery parameters or 
administering drugs without authorization. Alternatively 
the identification can be entered manually or via other 
5 data-entry means. 

As discussed above, in one embodiment the system uses 
the patient identification to check one or more databases 
as a cross check against the medication being provided to 
the patient in the instant infusion. 

10 After completion of the above, the system is ready 

for use as shown in step 97. Now, the clinician may bring 
the drug to be administered to the patient's bedside for 
installation in automated medication management system 3 00 
at step 98. The drug is identified, such as for example 

15 by barcode scan at step 99. If the drug does not have a 
barcode label, the clinician may identify it through a 
list imported from the network 71 or through a drug list 
residing in memory within the system or by manual data 
entry. 

20 In step 100, the system verifies that the identified 

drug, dosage, patient name, time of delivery, and route of 
delivery correspond with prescription information on file. 
Should all information be correct, in step 101, the system 
proceeds with its operation. 

25 The clinician is notified of inaccuracies and asked 

to correct them if he or she still wishes to proceed. 
However, in certain circumstances, such as for example 
where the requested dosage exceeds the maximum allowed 
level, the system does not allow or approve delivery. In 

3 0 one embodiment, the system can be overridden with the 
appropriate authorization. 
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At step 102, the clinician loads the desired drug 
vial 85 onto the cassette 77. For medications which are 
not delivered through cassette 77, the user enters the 
information into bedside control and delivery unit 50 so 
5 that the drug event data can be transferred to other 
databases within the hospital . 

In step 103, the system reconstitutes, dilutes, and 
infuses cassette-prepared medications. After infusion, 
the cassette is rinsed so that no incompatible drug 

10 reactions occur upon the next drug delivery cycle. 
Finally, at step 104, the system records all delivered 
drug events, whether administered through the cassette or 
through other routes. That information may be 

transmitted to other databases within the hospital. 

15 Figure 7 is a diagram illustrating a simplified 

exploded view of head unit 75 according to the example 
implementation illustrated in Figures 5A and 5B . Fluid 
delivery module 88 pneumatically operates cassette 77 so 
as to reconstitute vials 85. Inside unit 75 is the 

20 control and management unit 304 which controls overall 
operation' of Bedside control and delivery unit 50, using 
software 67 and database 92. 

A battery 105 or other alternative power source 
allows mobile use and uninterrupted operation in case of 

25 power failure. Bar code scanner 70 is shown reading a 
patient's identification bar-code on a wristband. Such 
information will eventually be recorded by Bedside control 
and delivery unit 50 as part of all drug events monitored 
or delivered by the present invention. 

3 0 Control and management module 3 04 controls fluid 

delivery module 77 so as to provide automated 
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reconstitution, dilution, infusion, and rinsing of 
medications delivered through cassette 77. Module 304 
also works to communicate with database 92 for 
verification and recording of all other medication 
5 deliveries. Fluid delivery module 88 operates on cassette 
77 so that fluids and air can be moved through cassette 77 
without any contact with fluid delivery module 88. In one 
embodiment, module 3 04 includes an X8 6 processor-based 
system such as, for example, a 386 CPU and associated 
10 peripherals. 


Example Implementation of Cassette 77 

Figure 8 is a detailed illustration of an example 
implementation of a cassette 77 with vials 85 mounted 
15 thereon according to one embodiment of the invention. The 
components and relevant materials of the cassette 77 
according to one embodiment are listed in the table below. 
Alternative materials can be used to implement cassette 
77. 

20 


25 


COMPONENT 

MATERIAL 



Valves 112 

Santoprene 281-64 

Mixing chamber 
diaphragm 

Santoprene 281-64 

Delivery chamber 
diaphragm 

Santoprene 281-64 

Control Wheel Seat 
Insert 

Santoprene 281-64 

Control Wheel Seat 
Base 

Pro Fax PD-62 6 from 
Himont 
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Midbody 113 

Monsanto Lustran ABS 
248-2002 (white) 

Control Wheel 600 

Monsanto Lustran ABS 
248-2002 (white) 

Front Cover 111 

BASF Terlux 2812TR 

Rear Cover 111 

BASF Terlux 2812TR 

Spikes 118 

Monsanto Lustran 24 8- 
2002 (white) 

Spike Covers 12 6 

Polyethylene 

Luer Lock Cap 

Polyethylene 

Vented Air Cap 

Polyethylene 


The cassette 77 according to this embodiment is now 
described. The cassette is comprised of a mid-body 113 

2 0 which contains the fluid delivery pathways and seats for 

the diaphragms and valves. Midbody 113 is ultrasonically 
welded to the two covers which sandwich the diaphragms, 
valves and control wheel 110 in an assembly. Spikes 118 
are separately molded pieces which are also ultrasonically 
25 welded to midbody 113 and inner and outer covers 111. 
Tubing is bonded to the cassette for both the proximal 117 
and distal ports 115 and air input port 116. Standard set 
components make up the remainder of the administration 
set . 

3 0 The cassette and set are packaged and sterilized to 

provide a sterile fluid pathway. All cassette and set 
materials have been tested for biocompatibility and meet 
ISO 10993 standards. Caps 126 on the three vial spikes 
118, the luer port 108, the proximal tubing port 117 and 
35 the distal tubing port 115 provide sterile barriers so 
that the set and cassette assembly is a closed loop system 
and is preserved sterile when it is removed from the 
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package. Once the cassette 77 is loaded in the Bedside 
control and delivery unit 50, the vial spikes 118 and luer 
port 108 are maintained sterile by keeping the caps 126 in 
place until the time of use for each respective port. 
5 On both sides of cassette 77 are rigid plastic covers 

111 covering cassette 77. Pressure conduction chambers 
109 and 110 have windows fashioned on inside cover 111, 
thus exposing the flexible diaphragm for each chamber. 
The valves 112 are formed in an analogous fashion. Fluid 

10 delivery module 88 can apply positive or negative pressure 
to the pressure conduction chambers 109 and 110. 

When applied to the flexible diaphragm covering 
pressure conduction chambers 109 and 110, the pressure 
acts to draw fluid into the chambers or expel fluid out of 

15 the chambers. The valves 112 are controlled by DC motors 
which are cam actuated. The cam actuation opens and 
closes valves 112. In this way, through a combination of 
positive and negative pressure applied to the chambers 109 
and 110, and the actuation of valves 112, fluid delivery 

20 module 88 can pump fluid from inlet line 117 into the 
vials 85, reconstitute the medicine therein, and withdraw 
the fluid from the vials 85 back into chamber 109. 
Repetition of fluid movement into a vial 85 and back into 
chamber 109 assures that the medicine is entirely 

25 reconstituted. This fluid can then be precisely diluted 
in chamber 109 which is denoted the mixing chamber. 
Chamber 110 is denoted the metering chamber because the 
fluid is precisely measured and pumped into outlet line 
115. Movement of fluids in this fashion is disclosed in 

30 U.S. Patent Nos . 4,848,872; 4,778,451; 4,786,800; 
4,804,380; 4,816,019; 4,826,482; 4, 976,162; 5, 088,515, 
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5, 178,182, 5,193,990, 5,241,985, 5,353,837; 5,364,371; 
5,401,342, which are incorporated herein by reference. 

Fluid delivery module 88 also possesses acoustic 
volume sensing technology whereby a loudspeaker transmits 
5 sound waves into an acoustic volume sensing (AVS) chamber 
of fluid delivery module 8 8 and thereby measures the 
resonant frequency of the AVS chamber. The AVS chamber 
of the fluid delivery module is in communication with 
chamber 110 of the cassette. By measuring the volume of 

10 air in the AVS chamber through resonant frequency 
monitoring, the volume of fluid within chamber 110 can be 
calculated by a microprocessor contained within fluid 
delivery module 88. In addition, should air bubbles be 
entrained in the fluid within the pressure conduction 

15 chamber 110, these bubbles will be detected by AVS. The 
microprocessor will monitor for the presence of air- 
bubbles and will not pump liquid containing bubbles from 
the cassette 77 to the patient. Instead, the 

liquid/bubble mixture is either pushed back to the fluid 

20 source 89 or will be kept in chamber 109 until it is safe 
to expel the bubble to 89. Air can enter vials 85 through 
the air channel 116, preventing a vacuum condition from 
occurring as vials 85 are drained into mixing chamber 109. 
Acoustic volume sensing technology is set out in U.S. 

25 Patent Nos . 5,211,201; 5,349,852; 5,526,844; 5,533,389, 
which are incorporated herein by reference. 

Fluid within cassette 77 is pumped into vials 85 from 
mixing chamber 109. The means by which vials 85 are 
attached to cassette 77 is illustrated in Figure 9 

30 according to one embodiment. Vial 85 is held by clamp 
125, part of a vial-loading mechanism discussed below. 

BNSDOCID: <WO 9910829A1_I_> 


WO 99/10829 


PCT/US98/I7002 


42 

Spike 118 has a lumen 119 through which fluids and air may 
pass into cassette 77. When vial 85 is mounted on spike 
118, the sharpened end of spike 118 pierces elastic seal 
120 of vial 85 so that lumen 119 is now in contact with 
5 contents of vial 85. The elasticity of seal 120 ensures 
an airtight seal about spike 118. Clamp 125 holds vial 85 
stationary during system operation. When vial 85 is not 
mounted, a protective cap 126 covers spike 118 to maintain 
sterility and to protect users as illustrated in Figure 
. 10 10. 

A downward view illustrating how cassette 77 mounts 
on unit 75 according to one embodiment is shown in Figure 
11. Spikes 118 and luer port 108 are shown without any 
connections. To mount cassette 77, outer door 78 is 

15 pivoted open in one embodiment. Inner door 87 pivots at 
its bottom to swing open. After cassette 77 is placed 
against fluid delivery module 88, inner door 87 is pressed 
shut. In one embodiment, spring-loaded cams 128 are 
pushed aside as door 87 closes. When inner door 128 is 

20 fully closed, cams 128 return to their locking position. 
In this way, inner door 87 is held with sufficient force 
against fluid delivery module 88 so that pneumatic drivers 
can apply positive and negative pressure against the 
diaphragms of chambers 109 and 110 without leakage of 

25 pressure . 

Figure 15 is a diagram illustrating a perspective 
view of a cassette 77 in proximity with a portion 1532 of 
automated medication management system 3 00 designed to 
accept cassette 77. As illustrated in figure 15, one or 
3 0 more openings 1534 are provided to allow FMS and/or AVS 
actuation to to control the operation of Pressure 
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conduction chambers 109 and 110 on cassette 77. Actuators 
1538 are used to control the operation of valves 112. 

Example implementations of cassette 77 are disclosed 
in in application numbers, titled "System, Method and 
5 Cassette for Mixing and Delivering Intravenous Drugs," and 
"Cassette for Intravenous -Line Flow-Control System." 
These documents are incorporated herein by reference to 
illustrated one example implementation of a cassette 77. 
Alternative implementations of cassette 77 can be used in 
10 conjunction with automated medication management system 
3 00, including numerous alternative currently commercially 
available cassettes . 

Vial Loading Mechanism 

15 Figures 12 and 13 illustrate a vial loading mechanism 

according to one embodiment of the automated medication 
management system 3 00. As would be apparent to one of 
ordinary skill in the art after reading this description, 
alternative vial loading mechanisms can be implemented. 

20 In order to connect the vials 85 to the cartridges 

77, the membrane seals 120 of vials 85 are pierced. The 
clinician accomplishes this by inverting each vial 85 and 
lowering the vial 85 onto the spike 118 so as to pierce 
seal 120 with spike 118. 

25 With reference to Figures 12 and 13, to prevent the 

clinician from accidentally contacting the spikes 118 and 
injuring oneself, a vial loading mechanism, indicated 
generally by the reference numeral 200 can be provided. 
Vial loading mechanism 200 includes a panel assembly 202. 

30 Panel assembly 202 has an upper portion 204 and a recessed 
portion 206. 
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In front of recessed portion 206, a plurality of 
holders 2 07 are provided. Each holder 207 includes an 
outer holding arm 208 and an inner holding arm 210. The 
outer holding arm 208 includes a proximate end 212 
5 adjacent to the panel assembly 202 and a distal end 214. 
The distal end 214 includes an arcuate holding portion 
216. A tang 218 extends inwardly from a lower part of one 
side of the arcuate holding portion 214. A groove 220 is 
provided in an upper portion of this side. A cutout 222 

10 is provided in the lower part of the opposite side of the 
arcuate holding portion 214. The groove 220 allows the 
head of the vial 85 to fit into the arcuate holding 
portion 216 and the tang 218 supports the head of the vial 
85. A rectangular cutout or slot 224 is provided in the 

15 outer holding arm 208 and is defined by a pair of opposing 
walls 226 and an end 228. 

The inner holding arm 210 is pivotally connected to 
the opposing walls 226. The inner holding arm 210 
includes a main body 23 0 with a sleeve 232 at one end and 

20 a penannular holding portion 234 at an opposite end. Both 
the arcuate holding portion 216 and the penannular holding 
portion may have corrugated, rubber on other friction- 
prompting inner surface to enhance the frictional 
engagement between the vial 85 and holding portions 216, 

25 234. A projection 236 extends in a generally lateral 
direction from the holding portion 234. 

The inner holding arm 210 is pivotally connected at 
the sleeve 232 to the walls 226 of the outer holding arm 
208 through a pen, or other similar fastening means. The 

30 inner holding arm 210 pivots from a raised (out-of-the- 
way) position to a lowered position, where the inner 
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holding arm 210 is stopped by a tang 237. Figure 12 
illustrates the inner holding arm 210 in both of these 
positions. Although not shown, a spring may be provided 
to bias the inner holding arm 210 to the raised and/or 
5 lowered position. Also, a locking device may be provided 
to retain the inner holding arm 210 in the raised and/or 
lowered position. 

With reference to Figure 13, a shaft 238 extends from 
the outer holding arm 208 at its proximate end 212 and 

10 terminates at a head plate 241. The shaft 238 vertically 
reciprocates within a bushing 240. The bushing 240 
includes a bore 242 and a lip 244. A helical spring 246 
surrounds the shaft 238. The spring 246 is disposed at 
least partially within the bore 242 of the bushing 240, 

15 between the lip 244 and the head plate 241. 

When the holder 207 is lowered, the shaft 238 
reciprocates within the bushing 24 0 and the spring 23 8 is 
compressed. This causes an upwards restoring force, in 
the opposite direction. 

2 0 To retain the holder 2 07 in a lowered position, a 

locking device 24 7 is provided. The locking device 24 7 
includes a warm- like locking arm 248 that extends 
alongside and in the same direction as each holder 2 07. 
The locking arm 24 8 includes a proximate end 25 0 and a 

25 distal end 252. Near the distal end 252, a moon- shaped 
cam 254 is provided. The cam 254 has a curved upper 
surface 256 and a flat lower surface 258. A curved 
projection 260 extends from the distal end 252 of the 
locking arm 248. Near the proximate end 250, the locking 

30 arm 248 is connected to the bushing 24 0 by a torsion or 
spring bar 261. The torsion bar 261 provides a restoring 
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force on the locking arm 24 8 when the locking arm is moved 
in a manner to be described. Alternatively, the locking 
arm 24 8 may have a construction that eliminates the need 
for a torsion bar 261. For example, the locking arm may 
5 be directly connected to the bushing 24 0 if the locking 
arm 24 8 is made of a resilient material. 

The vial loading mechanism 200 will now be described 
in use. The vial loading mechanism is designed to be used 
with two different, industry standard size vials a 13 

10 mm size vial and a 20 mm size vial, but can be built to 
utilize other sizes as well. 

If the 13 mm size vial is to be used, the clinician 
must make sure that the inner holding arm 210 is in the 
lowered position. This can be done by pivoting the inner 

15 holding arm 210 with the help of projection 236. The vial 
85 is inverted and the neck of the vial 85 is snapped 
into, or frictionally engaged with, the holding portion 
234 of the inner holding arm 210. The clinician forces 
the holder 2 07 to be lowered so that the spike 118 pierces 

20 the membrane seal 120 of the vial 85. Because the spring 
244 provides an upward force on the holder 207 when 
compressed, the holder 207 must be retained or locked in 
the lowered or locked position. This is accomplished 
through the locking device 247. As the holder 207 is 

25 lowered, the lower part of one of the walls 226 contacts 
the cam 224 of the locking arm 248, causing the locking 
arm 248 and cam 254 to move out of the way. The holder 
207 is further lowered until the locking arm is allowed to 
move back to its original, locked position. - In the locked 

30 position, the flat lower surface 258 of the cam 254 
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retains the holder 207 in this position, regardless of the 
restoring force of the spring 244 . 

The bedside device monitors whether the vial 85 is in 
the locked position by a vial -attachment sensor (not 
5 shown) . 

To remove the vial 85, the locking arm 24 8 is moved 
laterally with the projection 260 until the flat lower 
surface 258 of the cam 254 no longer blocks or retains the 
holder 207. The restoring force in the spring 244 causes 
10 the holder 207 to rise to its original position where it 
is maintained in an unlocked position by the force of the 
spring 244. The vial 85 is then removed from the holding 
arm 210 . 

In the event that a vial 85 or protective cap 126 
15 does not replace the unloaded vial, the system will 
disenable the cassette 77 in order to maintain aseptic 
conditions. 

If the 20 mm size vial 85 is used, the inner holding 
arm 210 must be located in the upward (out-of-the-way) 

2 0 position. This may be done by pivoting the arm 210 

upwardly using projection 256. This allows the larger- 
size vial 85 to fit within the arcuate holding portion 216 
of the holder 207 to be lowered onto the spike 118 in the 
same manner as that described above. 
25 The vial loading mechanism of the present invention 

provides an improved, safe, and easy way of loading, 
retaining, and unloading vials in a bedside delivery 
system. The vial loading mechanism inhibits clinicians 
from contacting the spikes 118 of the system and hurting 

3 0 themselves. 
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Example User Interface 

Figure 14 is a diagram illustrating an example user 
interface for an automated medication management system 
300 according to one embodiment of the invention. More 
5 specifically, figure 14 illustrates a specific interface 
implemented in conjunction with the bedside control and 
delivery units illustrated in figures 5A and 5B . As would 
be apparent to one of ordinary skill in the art after 
reading this description, automated medication management 

10 systems 3 00, including the bedside delivery and control 
units, can be implemented with alternative user 
interfaces. The description of the user interface now 
described is provided by way of example only. 

The user interface according to the embodiment 

15 illustrated in figure 14 is comprised of two sections, a 
user operation and interface section 504 and a display 
section 508.- Display section 508 includes indicator 
lights and displays to provide a clinician with 
information regarding medications being administered to a 

20 patient. Indicators 509A-509E provide the clinician with 
information as to which of a plurality of IV ports are 
currently being used to administer medication. In the 
embodiment illustrated, there are three IV ports as 
denominated by indicators 509B, 509C, and 509D, a luer 

25 port denominated by indicator 509E, and a primary port 
indicated by 509A. 

A rate indicator 511 provides a numerical display as 
to the rate at which medication is being administered to 
the patient. In a preferred embodiment, this is provided 

30 in units of ml/hr. Display 512 provides an indication of 
the volume of the medication which has yet to be 
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administered to the patient. In a preferred embodiment, 
this display is provided in units of milliliters. 

In one embodiment, indicators 511, 512 are 
implemented using LED or LCD display providing numerals of 
5 sufficient size and intensity such that they are easily 
legible. In alternative embodiments, alternative display 
technologies are utilized to provide a legible display. 

Power indicator 510 informs a user whether the system 
is running off of battery or AC power and an alarm 

10 indicator 513 provides an indication as to whether an 
alarm condition is present. These indicators are backlit 
such that the characters are illuminated when the 
indicator is activated. Alternative indicator types can 
be utilized as would be apparent to one skilled in the 

15 relevant art. 

User operation and interface portion 504 is comprised 
of a plurality of buttons and a display screen to function 
as the primary user interface for the system. a power 
button 519 is used to power the system on or to place the 

20 system in a stand-by mode. a keypad 514 is used to allow 
manual entry of data by a user. The keypad 514 
illustrated in figure 14 is a numeric keypad allowing only 
the entry of numeric data. In alternative embodiments, 
alphanumeric keys, function keys and other types of 

25 keypads can be provided to allow the entry of additional 
data. Additionally, a cursor control keypad 515 is 
provided to move a cursor on display screen 516. 

In the embodiment illustrated in Figure 14, display 
screen 516 is a computer display screen such as that 

30 commonly used in personal computers. Display screen 516 
can be used to provide information to the user and to 
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allow the user to enter control information. In one 
embodiment, the automated medication management system 300 
is a Windows-based system. In this embodiment, display 
screen 516 is used to provide menu options or window 
5 screens to the user to allow the user to control the 
system as well as to provide information regarding the 
operation of the system. a cursor keypad 515 is provided 
to allow the operator to position a cursor on display 
screen 516 to enable selection. 

10 Additional buttons 520 are provided to allow 

additional control selections to be made by the operator. 
Buttons such as option button 520A, O.K. button 520B, 
cancel button 520C # run/hold button 520D and non-IV button 
520E and menu button 520F are used to select a pull-down 

15 menu 524, confirm a selection, cancel a selection or 
operation, pause or resume an operation or to allow an 
operator to designate that a medication being administered 
is other than an I. V. -type medication. Indicators 517 are 
used to indicate which portions of display screen 516 

20 provide information with regard to particular I.V. ports. 

As stated above, alternative configurations can be 
provided for the user interface depending on the 
application and environment for the system. The 
embodiment illustrated in Figure 14 provides an example of 

25 a specific user interface in one embodiment of the system. 
After reading this description, it will become to a person 
skilled in the relevant art how to implement alternative 
user interfaces which allow control, operation and 
monitoring of the system. In a more generic embodiment, 

30 for example, the entire user interface can be implemented 
using a computer display screen in conjunction with a 
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keyboard and/or a mouse. In this embodiment, all of the 
control and display operations are accomplished using 
conventional computer interface techniques. 

5 Example Architecture For An 

Automated Medication Management System 300 

Figure 16 is a block diagram illustrating an example 
architecture for an implementation of automated medication 
management system 300. This example architecture is now 

10 described with reference to Figure 16 . After reading this 
description, it will be apparent to a person skilled in 
the relevant art how to implement automated medication 
management system 300 using alternative architectures. 

The architecture illustrated in Figure 16 is 

15 comprised of five primary modules: system board 1801, 
programming panel 1802, power supply board 1803, status 
panel 1804, and fluid delivery module 1805. Additionally, 
the architecture illustrated in Figure 16 includes several 
auxiliary elements. 

20 System board 1801 is primarily responsible for the 

control and operation of automated medication management 
system 300. System board 1801 is a processor-based board 
controlled by CPU 1855. In one embodiment, system board 
1801 is an X86 -based board capable of running the DOS or 

25. the Windows 3.1 or Windows 95 operating systems. In the 
illustrated architecture, RAM 1806 and program memory 1865 
are used to store data necessary for the operation of CPU 
1855. Instructions for controlling the operation of CPU 
1855 are stored in program memory 1865. RAM 1860 is used 

30 by CPU 1855 to store operating information. Additionally, 
battery-backed RAM 1850 is provided to store information 
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that needs to be maintained between power cycles of the 
system. A real time clock 1890 is provided to maintain 
synchronization of CPU 1855. 

System board 1801 also includes a tilt sensor 1835 
5 and a temperature sensor 184 0 to sense the operating 
environment of the system. These boards communicate with 
CPU 1855 via a sensor interface 1845. As would be 
apparent to one of ordinary skill in the art, additional 
sensors can be included to receive and provide data 

10 regarding the operating environment or numerous other 
parameters important to the operation of automated 
medication management system 300. In addition to the 
above -described components, system board 1801 includes a 
plurality of interfaces and controllers used in 

15 communication with the other modules, external 
peripherals, and other systems and devices. 

The interfaces include a power supply interface 1875, 
a status panel interface 1880, and IrDA interface 1885 
(infrared device interface) , a fluid delivery module 

20 interface 1895, a printer interface 1870, a PCMCIA 
interface 1861, an external serial interface 1859, an 
auxiliary FDM (fluid delivery module) interface 1858, an 
LCD controller 1857, a keypad controller 1854, and a bar 
code reader interface 1853. Each of these interfaces and 

25 controllers provide the communications necessary to 
interact with the devices and modules to which they are 
connected. Each of these interfaces and controllers are 
discussed below with reference to the modules and devices 
with which they interact . 

30 Programming panel 1802 is provided to allow an 

operator or user of the system to program or otherwise 
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control the operation of the automated medication 
management system 300. a key pad 1821 allows the user to 
enter data or control the operation of automated 
medication management system 300. Key pad 1862^ in one 
5 embodiment has a simple numeric key pad in combination 
with four arrow keys to provide cursor control . With a 
simple key pad such as this, a user can navigate his or 
her way around options displayed on a screen such as a 
CRT, and select those options to operate the system. More 

10 complex key pads including alphanumeric buttons and/or 
function keys can be utilized to provide additional levels 
of control. Key pad 1821 is interfaced to system board 
1801 by a key pad controller 1854. 

LCD display 1822 is utilized to provide a display to 

15 the user. Control information for operation of the system 
can be provided in the form of menus or other displays 
which can be used by the operator during normal operation 
of the system. LCD display 1822 interfaces with system 
board 1801 via LCD controller 1857. Although the 

20 embodiment illustrated in Figure 16 utilizes an LCD 
display, other types of displays can be utilized 
including, for example, a CRT type display. In addition 
to key pad 1821, input devices such as a mouse, joystick, 
or other data entry or control device can be utilized. 

25 Power supply board 1803 is used to control and 

monitor the power provided to automated medication 
management system 3 00. Power supply board 1803 

communicates with system board 1801 via power supply 
interface 1875 and includes a power supply monitor 1831, 

30 an AC power supply and charger 1832, a battery 1833, and 
voltage regulators 1834. Power supply board 1803 receives 

BNSDOCID: <WO 9910829A1_I_> 


WO 99/10829 


PCT/US98/17002 


54 

its source of power from a main power inlet 1818 and 
provides various system voltages 1898 to operate automated 
medication management system 300. AC power supply and 
charger, in combination with voltage regulators 1834, 
5 receives AC power from main power inlet 1818 and provides 
the necessary AC and/or DC voltages required to operate 
the system as system voltages 1898. Additionally, AC 
power supply and charger 1832 provides a charging signal 
utilized to charge batteries 1833. Batteries 1833 provide 

10 an alternative source of power for automated medication 
management system 3 00 should the AC power source become 
unavailable, substandard, or otherwise inadequate. Power 
supply monitor 1831 monitors the condition of the AC power 
supply and charger 1832, battery 1833, and voltage 

15 regulators 1834 to determine the condition and integrity 
of power sources and the power being provided to automated 
medication management system 300. Power supply monitor 
1831 utilizes this information to make decisions regarding 
the source of power for the system and to inform system 

20 board 1801 regarding the status of the power supply. 

Status panel 1804 is used to provide status and 
additional information to a user or operator of the 
system. Status panel 18 04 interfaces with system board 
1801 via status panel interface 1880. Status panel 1804 

25 includes an LED display and audio controller 1841 and an 
IrDA transceiver 1843. LED display and audio controller 
1841 provides drivers for an LED display 1842 and a 
speaker 1819. In this manner, audio and visual 

information can be provided to the user regarding the 

3 0 status and operation of the system. 
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IrDA transceiver 1843 is used to communicate with an 
external device having an infrared communication 
transceiver. IrDA transceiver 1843 provides the necessary 
conversions between the infrared communications signal and 
5 electronic communications signal such that system board 
18 01 can communicate with a device having an infrared 
communication port. IrDA transceiver 1843 communicates 
with system board 1801 via IrDA interface 1885. 

Fluid delivery module 1805 is a module responsible 

10 for controlling the admixture and delivery process. Fluid 
delivery module 1805 communicates with system board 1801 
via fluid delivery module interface 1895. More 
specifically, an SMP interface 1845 is provided to return 
status information regarding the operation of fluid 

15 delivery module 1805. - 

Printer 1817, which interfaces with system board 1801 
via printer interface 1870, is utilized to provide a hard 
copy printout of information relevant to the operation, 
maintenance and control of automated medication management 

20 system 300. 

A bar code reader 1812 is utilized to read 
information coded in the form of optical bar codes. The 
information from a scanned bar code is provided to system 
board 1801 via bar code interface 1853. Bar code reader 

25 1812 can be implemented using a hand-held bar code reading 
device which is easily positioned in proximity with the 
bar code to be scanned. Bar code reader 1812 can be hard 
wired or can have a wireless interface to bar code 
interface 1853. One form of bar code reader 1812 suitable 

30 for use with automated medication management system 300 is 


BNSDOCID: <WO 9910829A1_I_> 


WO 99/10829 


PCT/US98/17002 


56 

the type of hand-held bar code reader often seen at the 
checkout line of many retail establishments. 

Auxiliary FDM port 1813 which interfaces with system 
board 18 01 via auxiliary FDM interface 1858 is utilized to 
5 provide communications with one or more auxiliary fluid 
delivery modules. As such, system board 1801 can be 
utilized to provide control and operation of a plurality 
of fluid delivery modules. Serial port 1814 and network 
connection 1815 are utilized to provide communications 

10 interface with external entities. Serial port 1814 can be 
an RS-232 or other serial communications port and 
interfaces with system board 1801 via external serial 
interface 1859. .Network connection 1815 typically 
operates at a higher data rate than serial port 1814, and 

15 is utilized to connect system board 1801 to a network. In 
the embodiment illustrated in Figure 16, the network 
connection is made by way of a PCMCIA interface 1861. a 
PCMCIA interface is desirable due to its small size and 
low power consumption features. However, as will be 

20 apparent to one of ordinary skill in the relevant art, the 
network connection need not be of the PCMCIA variety. 
Extended memory 1816, utilized to store data, is also 
interfaced with system board 1801 via PCMCIA interface 
1861. Various components of system board 1801 are 

25 connected via system ADC lines 1862. In one embodiment, 
system ADC lines 18 62 are a conventional bus structure 
having address, data and control lines, as well as control 
logic necessary for the operation thereof. 

This architecture presented in Figure 16 is described 

30 to provide a detailed example of one possible 
implementation of an architecture for automated medication 
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management system 300. After reading this description, it 
will be apparent to one of ordinary skill in the art how 
automated medication management system 3 00 can be 
implemented using alternative architectures and that the 
5 implementation of an automated medication management 
system in accordance with the invention is not limited to 
the architecture depicted in Figure 16. Additionally, 
numerous features and components of an automated 
medication management system are described elsewhere in 

10 this document and are not illustrated as being implemented 
in the example architecture illustrated in Figure 16 . 
However, it will likewise be apparent to one of ordinary 
skill in the art how these additional components and/or 
features can be implemented in conjunction with this or an 

15 alternative architecture. 

Automated Health Care Environment 

As discussed above, the automated medication 
management system 3 00, in accordance with one or more 

20 embodiments, can be integrated with a health care facility 
through a network or other communication means. Figure 17 
is a diagram illustrating an example implementation an 
automated health care facility 800 according to one 
embodiment of the invention. As will be apparent to one 

25 of ordinary skill in the art after reading this 
description, numerous alternative architectures can be 
used to implement the health care facility and provide the 
described functionality. 

The automated health care facility 800 in this 

30 embodiment includes a network 804 which is used to 
integrate the various components of the health care 
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facility. Network 804 can be implemented using local-area 
or wide -area network technologies and can be a single 
network as illustrated in Figure 17, or can comprise a 
plurality of interconnected networks. Alternative 
5 techniques for interconnecting the elements of automated 
health care facility 800 can be utilized as well. 

The health care facility illustrated in the example 
embodiment * of Figure 17 , includes one or more pharmacies 
803, one or more administration entities 808, one or more 

10 automated medication management systems 300, one or more 
nursing stations 816, one or more sentries 834 one or more 
data servers 820, and one or more data entry terminals 
824. Also included in the illustrated embodiment are one 
or more external interfaces 83 0, as well as one or more 

15 automated admixture and delivery units 812. 

As would be apparent to one of ordinary skill in the 
art after reading this description, additional facilities 
can be integrated with the network to provide additional 
functionality to suit the particular implementation of the 

20 health care system. Additionally, portions of the 
described facility which may not be needed for particular 
implementations can be omitted. Furthermore, alternative 
configurations can be implemented without departing from 
the spirit and scope of the invention. 

25 The manner in which patient and medication 

information are handled in the health care facility is now 
described according to several example embodiments . As 
described above, health care professionals in the course 
of treating a patient often prescribe medication to be 
.30 administered to the patient. This information can be 
entered into the system using data entry terminals, such 
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as data entry terminals 824. These can be portable, (such 
as, for example, hand held, or otherwise transportable) 
data entry terminals or stationary data entry terminals 
located at convenient locations for the entry of data. 
5 Additionally, clinicians and other health care 
professionals can use these terminals to enter other 
information germane to the treatment of the patient and 
his or her stay at the facility. 

Examples of the types of data which can be entered in 

10 the data entry terminals 824 include patient information, 
medication information, and other information. Patient 
information can include, for example, the patient's vital 
signs, the patient's condition, patient allergies, 
existing patient medications, as well as other information 

15 which may be useful in the diagnosis or treatment of the 
patient. This patient information is ultimately stored on 
a patient database. 

In a typical hospital or other health care 
environment, information pertaining to the patient 1 s 

2 0 condition and the prescribed medications, dosage and 

dosing intervals are entered into the patient f s chart. In 
one embodiment of the invention, this information is 
entered into a database containing patient information for 
one or more patients at the health care facility. This 
25 database is referred to in this document as a patient 
database. This database can include additional 

information about the patient such as other medications 
the patient may currently be taking, either intravenously, 
orally, or otherwise; allergies the patient may have; 

3 0 patient demographics, such as, for example, the patient's 

age, weight, sex, and other like information; or other 
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relevant or pertinent information including other 
information from the patient's chart. All of the 
information normally found on the patient's chart may be 
stored in the patient database to create a "virtual chart" 
5 for the patient . This virtual chart can be linked by a 
communication interface to one or more entities or 
facilities such as a pharmacy and other facilities. In 
this manner, data from the chart can be accessed from 
multiple locations . 
. 10 The data entry terminal can be a portable data entry 

terminal that can be carried or otherwise transported by 
a health care professional from patient to patient; or one 
which is stationary and located, for example at a central 
location or in the patient rooms. 
15 In one embodiment, such information can also be 

entered using data entry device 312 in automated 
medication management system 300. In this embodiment, the 
information may be stored in automated medication 
management system 300 (such as, for example in data 

2 0 storage 316) as well as shared with other entities or 

databases through the use of communication interface 320. 

Data entry terminals 824 can include a wired or 
wireless communication interface providing direct or 
networked connection to the one or more entities or 
25 facilities with which the terminal communicates. For 
example, a fixed data entry terminal 824 located in the 
patient's room or near the patient, can have a hard-wired 
or wireless connection to network 804 so that information 
can be transmitted from data entry terminal 824 to the 

3 0 appropriate database or data server 820 or to pharmacy 
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803. The portable data entry terminal can include 
wireless or hard-wired communications as well. 

Additionally, in one embodiment the portable data 
entry terminal can store entered, data in a local memory as 
5 the health care professional is performing his or her 
rounds. In this embodiment, the health care professional 
may carry the portable data entry terminal 824 with him or 
her while conducting the rounds. As each patient is seen, 
examined or diagnosed, information pertaining to that 
10 patient obtained during the visit can be entered using the 
terminal. Such information can include the various types 
of patient information described in this document as well 
as a diagnosis of the patient and a prescription to treat 
the diagnosis. 

15 At the completion of the rounds, or at other periodic 

intervals, the data can be downloaded from the data entry 
terminal to appropriate elements in the health care 
facility. For example, in the environment of the health 
care facility illustrated in Figure 17, a prescription may 

20 be forwarded to pharmacy 803, patient information may be 
stored in patient database 836 , and so on. This can be 
done by wireless communications or by interfacing the 
portable data entry terminal to a hard-wired connection 
such as, for example, an RS232 port or a network interface 

25 card. 

Additionally, the communications between data entry 
terminals 824 and other network elements or other health 
care facility entities can be continuous (e.g., via an 
open channel of communication) or frequent enough such 
30 that the health care professional interacts with these 
entities and elements in real time. In this manner the 
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health care professional can receive feedback from these 
entities and elements as data is entered. For example, 
where a physician enters a prescription for a patient, the 
physician can receive real-time feedback regarding the 
5 propriety of administering the prescribed medication to 
the patient. As another example, where the physician 
enters a patient diagnosis and utilizes an analysis 
package to recommend treatments, the physician can receive 
real-time feedback. As illustrated by these two examples, 
10 in this embodiment, the physician can make on-the-spot 
decisions regarding therapies prescribed for the patient. 

In the embodiment illustrated in Figure 17, a patient 
database 83 6 is used to store the patient data information 

15 entered from patient data entry terminals 824. From the 
data regarding a patient, patient profiles can be created 
to provide a synopsis of pertinent information pertaining 
to the patient. Thus, the patient database can include 
detailed information regarding each patient as well as 

20 patient profiles. 

In the embodiment illustrated in Figure 17, a patient 
database 83 6 is illustrated as being accessed by a data 
server 820. In alternative embodiments, patient database 
83 6 can be located elsewhere within the architecture or 

25 distributed among a plurality of locations. 

A pharmaceutical database 805 is provided to store 
information relating to one or more of the medications 
dispensed by the pharmacy. This information can include 
drug IV template and other information such as drug 

3 0 interaction precautions, recommended doses, side effects, 
warnings and other information which may be relevant to a 
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decision regarding whether to administer the prescribed 
medication. Pharmaceutical database 805 can also include 
a hospital formulary list indicating the medications 
available to that pharmacy or for the hospital to which 
5 the patient is admitted. 

Although illustrated as directly tied to pharmacy 
804, pharmaceutical database 805 can alternatively be 
located elsewhere within the architecture or accessed by 
a server, such as, for example, data server 82 0 or 

10 distributed among several entities. 

In one embodiment, sensors 84 0 can be used to monitor 
a patient's vital signs and condition and to provide 
telemetry regarding the sensed patient information to 
update patient database 836. Additionally, information 

15 from sensors 84 0 can be used to provide information 
directly to the nursing stations 816. Examples of sensors 
84 0 can include heart rate, blood pressure, body 
temperature, and other sensors to sense a patient's 
condition. Sensors 84 0 can be hard wired to the network 

20 or other device or can use a wireless communication 
interface. Sensors 84 0 are illustrated as being 
interfaced directly to network 804. Alternatively, 
sensors 840 can be interfaced via one or more entities, 
such as, for example, data entry terminals 824. 

25 In one embodiment, when prescription information is 

entered into data entry terminal 824 (or via data entry 
device 312) , the prescription is forwarded to the pharmacy 
804. The delivery can be fully automatic, that is, 
delivery happens without further user intervention, or a 

3 0 command may be required to actually forward the 
prescription to pharmacy 804 . Pharmacy 804 can include 
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display screens, printers, terminals or other devices to 
provide the prescription information to the pharmacist . 
* Patient and other information can be provided to the 
Pharmacist as well. Upon receipt of this information, the 
5 pharmacist fills the prescription. 

Prescriptions sent to pharmacy 84 0 can also include 
an identification of the patient. According to one 
embodiment, patient database 83 6 is checked in conjunction 
with the prescription to determine whether the patient has 

10 any allergies, conditions, or other factors which may 
indicate that the prescribed medication is not ideally 
suited to that patient. This check can be used to help 
prevent the prescription and administration of medications 
to a patient where that patient has a condition which 

15 renders the medication unsuitable for that patient or 
where the patient has already been prescribe the same or 
another medication to treat the current condition. This 
check can be performed by comparing the prescription 
information with information stored in patient database 

20 836. A simple example of such a check would be to look 
into patient database 83 6 to determine whether the patient 
is allergic to the prescribed medicine. 

Additionally, the prescribed medication and 
information regarding the patient and his or her condition 

25 in patient database 83 6 can be compared against 
pharmaceutical database 805 to determine whether the 
patient has any conditions or there are other 
circumstances which would give reason to reexamine the 
decision to prescribe the identified medication. 

3 0 Such a check can be performed as the physician enters 

the prescription information into data entry terminals 
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824, and thereby provide real time feedback to the health 
care professional. At this point, the health care 
professional can decide whether to proceed with the 
original- prescription, performing a preemptive override of 
5 future alarms if necessary, change the prescription, or 
perform further investigation, examination, tests, or 
studies to determine the appropriateness of the prescribed 
therapy. 

This check can also be performed by pharmacy 804, 

10 automated medication management system 3 00, or other 
entity having access to this information. In one 
embodiment a sentry 834 is provided specifically to 
perform this medication-error-prevention function. In 
this embodiment, sentry 834 is a dedicated device which 

15 examines one or more of patient information, patient 
profiles, prescription information, and pharmaceutical 
information to determine whether the prescribed 
medication, dosage, and dosing interval are appropriate. 
Again, this can be done in real-time to provide immediate 

20 feedback, or offline. 

Once a prescription is checked to determine whether 
it is appropriate a message can be generated and provided 
to various elements of the health care facility. For 
example, where real-time feedback is provided to the 

25 prescribing physician, a message may be sent indicating 
the prescription was entered and accepted; or that the 
system has determined the prescription to be inappropriate 
and the reasons why such a determination has been made, 
and perhaps suggestions of alternative therapies to be 

3 0 prescribed. Such messages can assist the physician in 
making decisions regarding the treatment of patients. 
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Administration 808 can utilize information obtained 
by a network 804 to enhance and further automate the 
administration functions performed by the health care 
facility. For example, administration 808 can use drug 
5 event information and patient information to update its 
billing records; maintain and manage inventory; schedule 
the availability of operating rooms, hospital beds, 
diagnostic and/or treatment equipment; and schedule or 
manage the use of other health care facilities. 

10 Additionally, it may be desired to have pharmacy 804 
maintain its own inventory, especially for critically 
controlled substances. Thus, in one embodiment, certain 
inventories can be performed by administration 808 and 
others by pharmacy 804. 

15 Administration 808 can have its own dedicated 

databases 862, or can utilize databases interfaced to data 
server 820. Additionally, administration 808 can draw 
data from existing databases serving other network 
entities . 

20 Automated admixture and delivery systems 812 can 

retrieve information from and provide information to 
network 804. As described above, in one embodiment, 
automated admixture and delivery systems 812 can be 
relocated and interfaced to network 804 as needed for data 

25 transfers. For example, automated admixture and delivery 
systems 812 can be moved from one patient to the next to 
deliver medication. In one embodiment, an example 
implementation of an automated admixture and delivery 
system 812 can be an automated medication management 

3 0 system 3 00. 
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Data server 820 can be used to provide interface to 
one or more databases such as, for example, patient 
database 836. Other databases as needed or desired can be 
interfaced via data server 820 to network 804. 
5 Additionally, in an alternative configuration from that 
illustrated in Figure 17, databases such as pharmaceutical 
database 805 and administration database 8 62 can be 
accessed via data server 820. As will be apparent to one 
of ordinary skill in the art after reading this 
10 description, data server 820 and its associated database 
can use mirroring, shadowing, or other techniques to 
provide redundancy as a safeguard against lost or tainted 
data. 

Nursing stations 816 can be provided at various 

15 points throughout the health care facility to provide a 
location for nurses, clinicians, and other health care 
professional to enter data into network 8 04 or to retrieve 
data from network 804. In one embodiment, nursing 
stations 816 are implemented using a PC or other small 

20 computer with a network interface. Alternatively, they 
can be implemented using a terminal with a keyboard, mouse 
and monitor. Data entry devices such as, for example, a 
bar code reader may be provided as well. a nursing 
station 816 implemented with data entry capabilities can 

25 be used as an alternative (or in addition to) data entry 
terminals 824 to enter patient and other information. 

Additionally, a printer may be provided at nursing 
stations 816 to provide hard copy printouts for use in the 
treatment of patients and the administration of the health 

30 care facility. Additionally, a printer at nursing 
stations 816 can be used to create and print bar code 
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labels to be used for things such a patient identification 
and other identification tasks. Printed labels can be 
provided with a sticky back so that they can be affixed to 
the patient's chart, or other items appropriate for 
5 identification. 

In one embodiment, nursing station 816 includes a 
port for interfacing to the portable data entry terminals. 
In this embodiment, the health care professional 
interfaces the portable data entry terminal with the 

10 nursing station to download data to network 804. 

External interface 83 0 can be used to provide an 
interface for network 804 to the outside world. Such an 
interface can be used to contact suppliers for supply 
information and ordering, to provide information to health 

15 care professionals outside of the hospital, and for other 
communication interfaces. 

The automated health care facility can also include 
an analysis feature to assist the health care 
professional, such as the tending physician for example, 

20 in determining a suitable medication to prescribe for the 
patient based information such as patient information, 
medication information, and other information which may be 
relevant. In this aspect of the invention, an analysis 
package is provided which considers a diagnosis of the 

25 patient, patient information from the database as well as 
information pertaining to the medications available in a 
designated pharmacy to suggest to the physician which 
medications may be appropriate to administer to the 
patient, and at what dosage levels and intervals. The 

3 0 package may provide list of alternative medications which 
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can be used to treat the diagnosed condition and may also 
recommend alternative treatments or therapies as well. 

According to this analysis package, the system 
accepts the diagnosis of the patient as entered by the 
5 physician and checks the pharmaceutical database to 
determine which medications available in the formulary may 
be appropriate to treat the diagnosed condition. In one 
embodiment, the system may also recommend medications not 
in the hospital formulary. 

10 Medication information available in one or more 

databases, such as, for example IV template information 
described below, is used to suggest recommended dosage 
levels and intervals to the physician for the suggested 
medications. The prescription analysis feature may also 

15 use other patient information to assist in the decision 
making process, such as, for example, patient allergies, 
patient demographics, other patient medications, or other 
patient information provided in the patient database or 
entered by the physician. 

20 The analysis package may rule out certain medications 

or highlight other medications based on this additional 
patient information. The analysis package may also 
recommend specific dosage levels based on the patient 
information. According to another aspect of the analysis 

25 package, the system may prompt the physician to enter 
additional information to aid in the decision making 
process. For example, consider a scenario where the 
patient's weight is not available in the patient database 
and this information is desired to accurately determine 

3 0 the dosage level. The system may ask the physician to 
enter the patient's weight into the system. Ideally, 
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however, all of the patient's key information is already 
entered into the system or otherwise available from a 
database . 

In one embodiment, the analysis package also provides 
5 the health care professional with additional information 
pertaining to the recommended medications. For example, 
the physician may request a list of side effects for a 
recommended medication. This information can be used to 
assist the physician in the decision-making process as 
10 well as to allow the physician to pass this information on 
to the patient . 

This additional information, such as side effects and 
other information can also be provided to other 
professionals such as the health care professional 
15 administering the medication. In this manner, the 
administering clinician can inform the patient of likely 
side-effects at the time of administration. 

In one embodiment, such information can be provided 
to health care professionals at a terminal such as a data 

2 0 entry terminal 824 and can be protected based on clearance 

levels. 

Additionally, links may be provided to on-line 
references and documents or to references and documents 
available on the Internet, for example, to provide the 
25 health care professional with quick and easy access to 
available on-line resources. For example, CD-ROM or other 
electronic versions of the Physicians Desk Reference or 
other documents may be provided and linked for access via 
data entry terminals 824 or other terminals. 

3 0 Figure 17 provides a representative functional 

architecture for the health care facility. As would be 
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apparent to one of ordinary skill in the relevant art 
after reading this description, the functionalities 
described herein can be distributed among entities in 
alternative architectures. 

5 

Example Architecture For An Order Entry Terminal 

Figure 18 is a diagram illustrating an example 
architecture for a data entry terminal 824 according to 
one embodiment of the invention. Data entry terminal 824 

10 in this embodiment includes a controller 1904, which 
controls the operation of the terminal. Controller 1904 
may be implemented, for example as a microprocessor or 
other processor-based system. 

A display 1908 and appropriate display drivers (not 

15 illustrated) can be used to provide messages to the user. 
Display 1908 can be implemented using, for example, an LCD 
display, an active matrix display, a CRT or other display 
device. Other indicators, such as, for example, LED' s or 
other indicator lights can be used as well . 

20 A speech synthesizer 1912 can be provided to compose 

vocal messages to be provided to the user. Both the 
display and the vocal messages can be used to prompt the 
user for input, inform the user of medication alerts or 
provide other messages to the user. For a hand-held 

25 device, a smaller display, such as an LCD display may be 
desired. For a larger device, a partial or full size CRT 
screen will provide more area for display. 

In an embodiment where the physician enters a 
diagnosis and the system provides suggestions regarding 

3 0 possible medications to prescribe, information regarding 
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those medications and links to other references, a larger 
screen may be more desirable, although not required. 

Keypad 1916 can be used to provide data entry to the 
user. Keypad can be numeric or alphanumeric and can 
5 include function keys or other special keys. 
Alternatively a full keyboard and mouse or other pointing 
device can be provided. In a hand-held device, it is 
generally desirable to use a smaller keyboard or even a 
keypad. For a stationary terminal a full keyboard 

10 provides additional flexibility. 

Databases 1920 are illustrated as a part of data 
entry terminal 824. As discussed above, patient and/or 
medication information can be stored locally. In 
alternative embodiments, databases 192 0 are not required 

15 and the data is retrieved by communications interface 
1924 . 

Processing of information to perform prescription 
checks or prescription analysis can be performed locally, 
for example by controller 1904, or remotely by sentry 834, 
20 pharmacy 803 or other processing element. 

Communications interface 1924 provides uni- or bi- 
directional communications with other entities. Interface 
1924 can be a serial or parallel interface and can be 
wired or wireless. Peripherals 1932 can be interfaced to 
25 the terminal as well, including printers, disk drives and 
other devices. 

A code reader 1928, such as for example, a bar code 
reader, magnetic code reader, or other reader may be 
interfaced as illustrated. Code reader can be integrated 
3 0 with the terminal or in a separate housing. 
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The integrated embodiment is ideal for the hand-held 
implementation. In the integrated embodiment, the reader 
may be disposed in the housing of the terminal with a 
window or other "receiver" positioned, for example, at the 
5 top edge of the terminal or on the bottom side of the 
terminal. In this manner, the hand-held terminal can be 
held up to the bar code, or magnetic stripe or other code 
and read the code. No wires or separate housings are 
required. 

10 For an embodiment where the reader is separate, the 

reader may be hand-held and moved about freely such that 
the scanner can be positioned to read codes. The reader 
may be either wired or wireless. Either version, and 
particularly the wireless version, may have internal 

15 storage to allow storage of read data and downloading via 
batch transfers. 

As would be apparent to one skilled in the art after 
reading this description, alternative architectures can be 
provided for implementing data entry terminals 824. 

20 

Hardware And Software Implementations 

The various devices, components, and entities 
described above and illustrated in block diagram form may 
be implemented using hardware, software or a combination 

25 thereof and may be implemented in a computer system or 
other processing system. In fact, in one embodiment, 
these elements are implemented using a computer system 
capable of carrying out the functionality described with 
respect thereto. An example computer system 702 is shown 

30 in Figure 19. The computer system 702 includes one or 
more processors, such as processor 704. The processor 704 
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is connected to a communication bus 706. Various software 
embodiments are described in terms of this example 
computer system. After reading this description, it will 
become apparent to a person skilled in the relevant art 
5 how to implement the invention using other computer 
systems and/or computer architectures. 

Computer system 702 also includes a main memory 708, 
preferably random access memory (RAM) , and can also 
include a secondary memory 710. The secondary memory 710 

10 can include, for example, a hard disk drive 712 and/or a 
removable storage drive 714, representing a floppy disk 
drive, a magnetic tape drive, an optical disk drive, etc. 

The removable storage drive 714 reads from and/or writes 
to a removable storage medium 718 in a well known manner. 

15 Removable storage media 718, represents a floppy disk, 
magnetic tape, optical disk, etc. which is read by and 
written to by removable storage drive 714 . As will be 
appreciated, the removable storage media 718 includes a 
computer usable storage medium having stored therein 

20 computer software and/or data. 

In alternative embodiments, secondary memory 710 may 
include other similar means for allowing computer programs 
or other instructions to be loaded into computer system 
702. Such means can include, for example, a removable 

25 storage unit 722 and an interface 720. Examples of such 
can include a program cartridge and cartridge interface 
(such as that found in video game devices) , a removable 
memory chip (such as an EPROM, or PROM) and associated 
socket, and other removable ' storage units 722 and 

30 interfaces 720 which allow software and data to be 
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transferred from the removable storage unit 718 to 
computer system 702. 

Computer system 702 can also include a communications 
interface 724. Communications interface 724 allows 
5 software and data to be transferred between computer 
system 702 and external devices. Examples of 

communications interface 724 can include a modem, a 
network interface (such as an Ethernet card) , a 
communications port, a PCMCIA slot and card, etc. 

10 Software and data transferred via communications interface 
724 are in the form of signals which can be electronic, 
electromagnetic, optical or other signals capable of being 
received by communications interface 724. These signals 
are provided to communications interface via a channel 

15 728. This channel 728 carries signals and can be 
implemented using a wireless medium, wire or cable, fiber 
optics, or other communications medium. Some examples of 
a channel can include a phone line, a cellular phone link, 
an RF link, a network interface, and other communications 

2 0 channels. 

In this document, the terms "computer program medium" 
and "computer usable medium" are used to generally refer 
to media such as removable storage device 718, a hard disk 
installed in hard disk drive 712, and signals on channel 
25 728. These computer program products are means for 
providing software to computer system 702. 

Computer programs (also called computer control 
logic) are stored in main memory and/or secondary memory 
710. Computer programs can also be received via 
30 communications interface 724. Such computer programs, 
. . when executed, enable the computer system 702 to perform 
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the features of the present invention as discussed herein. 
In particular, the computer programs, when executed, 
enable the processor 704 to perform the features of the 
present invention. Accordingly, such computer programs 
5 represent controllers of the computer system 702 . 

In an embodiment where the elements are implemented 
using software, the software may be stored in a computer 
program product and loaded into computer system 702 using 
removable storage drive 714, hard drive 712 or 

10 communications interface 724. The control logic 
(software), when executed by the processor 704, causes the 
processor 704 to perform the functions of the invention as 
described herein. 

In another embodiment, the elements are implemented 

15 primarily in hardware using, for example, hardware 
components such as application specific integrated 
circuits (ASICs) . Implementation of the hardware state 
machine so as to perform the functions described herein 
will be apparent to persons skilled in the relevant 

20 art (s) . 

In yet another embodiment, elements are implemented 
using a combination of both hardware and software . 

JV TEMPLATES 

25 In one embodiment, software is provided enabling the 

pharmacy to choose their formulary drugs and the 
respective drug delivery parameters from a comprehensive 
list of alternatives. One or more of the drugs in the 
formulary will preferably have a list of parametric limits 

30 associated with it. For example an IV template can 
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contain the following fields of information relative to 
the mixing and delivery of a medication: 


Sample Template Fields 

Contents 



Diluent Exceptions 

Diluents which are 
prohibited from being 
used with the specified 
drug 

Additive Exceptions 

Additives which are 
added to the IV 
solution source and are 

used with the specified 
drug 

I v lClVV J- lllU.HI UCllVCiy IVCLL.O 

Mavi rmim Hoi "i ~\r£x ~Y"\r rat"0 
vi ctyL _!_ 1 1 l u. u i uciivciy IClLc 

set by the pharmacist 
for a specific drug 

Maximum Dilution Volume 

Maximum volume to be 
infused set bv the 
pharmacist for a 
specific drug 

Minimum Delivery Rate 

Minimum delivery rate 
for the corresponding 
drug 

Minimum Dilution Volume 

Minimum volume to be 
infused for the 
corresponding drug 

Nominal Delivery Rate 

Delivery rate 
recommended by the 
pharmacy for the 
corresponding drug 

Nominal Dilution Volume 

Recommended volume to 
be infused by the 
pharmacy for the 
corresponding drug 
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Nominal Reconstitution Volume 

Volume of diluent to be 
used in the 
reconstitution 

Stability Time 

Time which drug will 
remain stable after 
reconstituting and/or 
diluting 

Drug Requiring Reconstitution 

Indicate whether drug 
is powdered or 
lyophilized requiring 
reconstitution 


The pharmacy can then set the IV Template parameters 
to preferred values. Once the parameters are set for the 

10 medications in the hospital pharmacy formulary, the data 
can be imported via, for example, wired or wireless 
communication, or the network, into each bedside device 
where it is resident for dose administration, or in the 
data entry terminals where it is resident for prescription 

15 entry. When the hospital formulary is changed from time 
to time, the pharmacy may add or delete items from the 
pharmaceutical database. 

As discussed above, automated medication management 
system 3 00 allows the clinician identify the drug and the 

20 diluent during setup via the bar code scanner or selection 
from a drop down menu or entry via other user interface. 
In one embodiment, the identified drug must match an item 
in the pharmaceutical database for the system to begin 
mixing and/or infusing. Once the match is made by the 

25 present invention, the recommended mixing and/or delivery 
parameters are ^displayed on the user interface for the 
clinician to review. The parameters can be changed by the 
clinician as long as the change conforms to the minimum 
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and maximum recommendations set forth in the 
pharmaceutical database. If the change does not conform, 
the clinician is notified that the parameters are out of 
range. In one embodiment, administration of the 

5 medication will not be permitted to proceed unless a 
professional with the proper level of authorization allows 
the out of range delivery. 

In the event that the IV solution source is 
prohibited according to the pharmaceutical database for an 

10 inappropriate diluent or incompatible additive, the 
clinician may be required to change the solution source 
container to an appropriate diluent with the proper 
additive. After changing the solution source container, 
the system automatically reprimes the fluid pathways with 

15 the new diluent prior to beginning the cycle. 

instructions £qx Use 

In one embodiment, the general sequence of steps for 
the user to operate the automated medication management 
20 system for delivery of an IV drug, is as follows: 


25 


SECTIplf 

CONTENTS 



1. Instrument Preparation 

Turn power on and load 
cassette and set if IV 
delivery is desired 
through the device 
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2. Selecting the IV Source 
Solution 

Identify Patient ID and 
Clinician ID by bar 
code scan or keypad 
entry. 

Identify IV Source 
Solution by bar code 
scan or select from 
displayed list 
Select the prescribed 
base solution additives 
from the displayed list 
and enter the volume 
for each with the 
keypad 

3 . Priming the Delivery Set 

Press Prime key to 
automatically prime the 
proximal tubing and 
cassette 

Press and hold Prime 
key to prime the distal 
tubing 

4 . Loading the Vial 

Insert the vial into 
the adapter and press 
the vial on to the vial 
spike until the vial 
retention latch clicks 
into place . ( The 
device will acknowledge 
that the vial is loaded 
properly and prompt 
user) 

The clinician is 
reminded to utilize 
aseptic techniques to 
avoid touch 
contamination of the 
vial spikes or luer 
port adapter. 
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5. Scheduling Primary 
Delivery- 


Select the Primary 
Delivery key 
Enter the Rate and. 
Volume To Be Delivered 
Enter time for delivery 
to begin ( If there is 
a scheduling conflict 
the user will be 
prompted to change the 
start time) 


6 . Scheduling a Vial Port 


Press a Vial Port Key. 
Scan the vial bar code 
or select the drug from 
the displayed list. 
The IV Template 
information in the 
Pharmacy preset will be 
displayed. 

Clinician may change 
the delivery rate, 
duration of delivery 
and total dilution 
volume within the 
Pharmacy boundary 
limits . 

If the scheduled 
delivery time exceeds 
the respective Drug 
Stability time, the 
clinician will be 
prompted to change the 
delivery time. 
If there is an 
incompatibility with 
the IV Source Solution 
or Additives, the 
Clinician will be 
prompted to change the 
IV Source Solution 
container. After 
changing, the device 
will automatically 
reprime fluid pathways 
with new IV Source 
Solution . 


BNSDOCID: <WO 9910629A1_I_> 


WO 99/10829 


PCT/US98/17002 


82 


Scheduling the Luer Port 

Press the Luer Port key 
Scan the bar code or 
select the drug from 
the displayed list. 
The IV Template 
information in the 
Pharmacy preset will be 

d 3 c?r"N 1 pvpH 

Clinician may change 
the delivery rate, 
duration of delivery 
and total dilution 
volume within the 
Pharmacy boundary 
limits . 

Starting Admixture and 
Delivery 

After scheduling the 
ports, the clinician 
presses run and the 
fluid delivery cycle 
begins 


This sequence is provided as an example only to 
illustrate the operation of one embodiment of the 
invention. After reading this description, it will become 
10 apparent to one of ordinary skill in the art how 
alternative embodiments may be operated using alternative 
procedures . 

Figure 2 0 provides an overview of an example 
automated medication management system 300 according to 

15 one embodiment. After powering automated medication 
management system 300 on, if the system is connected to 
the network, the system checks the version of the software 
resident in the system with that available over the 
network. If the system's version does not match the 

20 version carried on the network, the system updates the 
version and operates off that new version. 
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The clinician enters a password to enable the system 
to unlock the front panel and display a start-up screen. 
The front panel lock feature can be set up by the health- 
care facility in a preference-setting section within the 
5 software so that after a timeout period of no activity has 
expired, the instrument automatically goes into front 
panel lock. This provides security against unauthorized 
use of automated medication management system 300. The 
user may also enter into front panel lock on a 

10 predetermined command. 

After display of the startup screen, the clinician 
may press a number of different keypad buttons to access 
different routines. If any of the keypad buttons P, 1, 2, 
3 or L are pressed, the system checks whether a cassette 

15 is loaded. Should a cassette be loaded and be 
uncompromised, the system proceeds to the cassette priming 
procedure, illustrated in Figure 23. 

Figure 21 illustrates a Patient ID Routine according 
to one embodiment. This routine describes a sequence of 

20 events for identifying the patient to automated medication 
management system 3 00. Whether this feature is enabled can 
be determined by the health care facility. If the patient 
identification feature is not desired, the system exits 
this subroutine immediately. Should patient ID be 

25 desired, the system checks to see if the patient ID has 
already been entered. If it has not already been entered, 
it can now be entered via bar code, or it can be entered 
via keypad entry. The identification can be in the form 
of the patient ID number or the patient's name or other 

30 code. This information can be used for accessing one or 
more databases to pull the patient profile information or 
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other patient information. By accessing such data, 
automated medication management system 3 00 can perform 
medication error checking. 

Figure 22 illustrates a Clinician ID Routine 
5 according to one embodiment of the invention. The 
clinician ID routine is analogous to that performed for 
the patient ID as described above with reference to Figure 
21. Clinician ID is performed according to facility 
preference. Should a health care facility prefer to track 

10 information based on a particular clinician's actions, the 
identification feature can be enabled. The system can 
accept a barcode or a keypad entry of the clinician's ID, 
name, PIN or other identifiers. 

Figure 23 illustrates a cassette loading and priming 

15 procedure according to one embodiment. After a clinician 
opens and closes both the inner and the outer door, the 
system determines whether a cassette 77 is in place. In 
one embodiment, should cassette 77 be present and have 
been used before, it will have been irreversibly 

2 0 compromised by operation of the two shut -off valves or by 
some other means. If the cassette is not compromised, 
then the clinician may proceed to the cassette priming 
sequence. If any of the P, 1, 2, 3 or L buttons are 
pressed on the keypad, the system checks to determine 

25 whether a cassette 77 is in place. If no cassette 77 is 
in place, automated medication management system 300 
prompts the clinician to install the cassette and performs 
a check for a compromised cassette. 

Once cassette 77 is loaded, the system prompts the 

30 clinician to identify the primary solutions for 
administration by either bar code scan of the solution 
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container label, or to enter in all the components of that 
solution via a set of lists that are supplied in the user 
interface. Should the patient profile or other patient 
information be available, the system checks the solution 
5 being administered versus what was actually prescribed. 
Should the system find no errors, it initiates "automatic 
priming." The user is prompted to press w OK, " and then 
the system automatically primes the cassette from the bag 
all the way to the distal exit port. At this point, the 

10 system then initiates a manual priming sequence, which is 
a user-activated and controlled sequence. The system 
prompts the user to press and hold a prime button until 
the user sees fluid coming out the distal end of the tube, 
at which point the user releases the button. 

15 Once the cassette is properly primed, the user can 

press P, 1, 2, 3, or L. Automated medication management 
system 3 00 begins the programming sequence the selected 
port. For example, in figure 31, the £ button has been 
pressed. This indicates that the primary solution 

20 delivery, or the primary port, is about to be programmed.' 
When the primary button is pressed, programming of that 
port is initiated. All parameters that have been 
previously entered appear for modification or verification 
and approval. Empty data fields such as rate of delivery 

25 or the volume to be infused (VTBI) can be entered. 
Required data fields, as determined by the hospital, must 
be completed. Upon entry of the necessary data, the user 
is prompted to approve the entries by pressing OK. When 
"OK" is pressed, the port is programmed and the programmed 

3 0 operation is initiated. 
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Figures 32A and 32B are flow diagrams illustrating 
programming of ports 1, 2, and 3 according to one 
embodiment. Ports 1,2, and 3, are the vial attachment 
ports. When a port button is pressed, the instrument 
5 prompts the user to identify the drug by either scanning 
the bar code of the drug vial, or selecting the drug from 
the drugs that are listed in the current Patient Profile 
(networked), or by use of a larger drop down list. If the 
drug is selected from the comprehensive list and not from 

10 the patient profile, the drug name is again displayed for 
verification. This action forces a review of the planned 
action for correctness of drug and patient, and helps to 
reduce medication errors. 

If the drug was identified via a bar code scan, the 

15 bar-code-scanned drug can be checked against data such as 
the patient profile. If the drug is present on the patient 
profile list the user is allowed to proceed. If not 
present, the user is notified of the situation and asked 
to review their planned action for correctness of drug and 

20 patient. The user is also asked if they still wish to 
proceed. 

Once the drug has been identified, and verified 
against the patient profile, and/or accepted by the user, 
the instrument references the IV templates. Information 

25 in the IV templates includes the final dilution volume, 
the diluent the drug will be put into, solutions this drug 
is compatible or incompatible with, suggested rates of 
delivery, reconstitution volumes , and other data elements 
important to the safe delivery of this drug. The user 

30 can confirm those settings or make modifications to fields 
where permitted. Once this programming is complete, the 
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instrument checks the drug to primary solution 
compatibility. If the drug and solution are compatible, 
all the programming is done and the instrument prompts the 
user to attach the drug vial to the port, this is Vial 
5 Attachment Routine, illustrated in Figure 24. 

The Vial Attachment Routine Flowchart highlights two 
levels of sensing on the vial attachment mechanism. The 
ability to sense whether the vial loading mechanism is up 
or down, and the ability to detect whether the vial 

10 attachment locking mechanism is locked or unlocked. These 
sensing mechanisms enable the instrument to monitor ports 
that are being manipulated to notify the user of the 
appropriateness of their actions. If the vial lock 
mechanism was moved from the locked to the unlocked 

15 position on an incorrect port, the instrument warns the 
user of the consequences of proceeding and the user is 
able to recover from that situation. 

Once the vial has been correctly attached, the user 
is instructed to schedule the delivery of this medication 

20 as illustrated on charts 24 and 25. The ability to 
schedule medication for delivery in advance is a key 
feature of the device. In one embodiment, the delivery 
can be scheduled as much as 24 hours in advance. 

A drug to diluent incompatibility process, 

25 illustrated in figure 33, demonstrates a process the 
instrument and user go through if it is determined that 
the drug and the primary solution (diluent) are 
incompatible. In this situation, if the solution is 
incompatible with the drug, the instrument first looks at 

30 port L to see whether it is available for use. If port L 
is not already programmed for use, the instrument suggests 
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a different solution source to be attached to that port 
for use with this drug when it is time to deliver that 
drug. If the Luer port is active and in use, the system 
suggests that the user schedule the incompatible drug to 
5 be delivered at some later time. 

Figure 34 generally outlines a network routine and 
checking of the Patient Profile according to one 
embodiment . The Luer port programming 

.10 Figures 35A, 35B and 35C are a flow chart illustrating a 
luer port programming routine according to one embodiment 
of the invention. Flow diagram 3 5A describes the 
instrument operation when the L button is pressed on the 
keypad. This is a similar program to the Vial Port 

15 programming except for one difference: There is no 
reconstitution or dilution done on the Luer port in this 
embodiment. The Luer port is for use with a pharmacy- 
prepared admixture that may come in a mini -bag, a syringe 
or a larger volume container. The instrument would prompt 

2 0 the user to identify the drug by one of the three means 

mentioned earlier; bar code scanning the label, by pulling 
the drug name from the Patient Profile List, or going to 
the larger comprehensive list. The instrument performs 
the check in the case of the bar code scanned drug or a 
25 drug selected from the larger list to make sure that it 
was the drug for this patient. The drug is scheduled for 
delivery in a similar fashion as the vial ports. 

Whether a vial port or a luer port, after each drug 
is delivered, the instrument preferably thoroughly rinses 

3 0 the cassette fluid paths, spikes, and in some cases the 

vials themselves to adequately clear any drug residual 
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that could cause future compatibility problems. In the 
case of an incompatibility between a drug and solution, 
the instrument also rinses any incompatible solutions 
from the cassette prior to beginning the mixing of the 
5 drug with the new compatible solution. 

The flowcharts illustrated in figures 25-28 are 
related to the medications that are delivered outside of 
the automated medication management system unit. These 
could be oral, topical, eye drops, eardrops, suppositories 

10 lotions, and other IV s that are not delivered through 
automated medication management system 300 in one 
embodiment. Once the Other Meds button is pressed, the 
instrument performs the drug identification routine, 
Patient Profile, and other operations to check for 

15 administration of medication. The same checks for 
correctness of information can occur. Because automated 
medication management system 300 in this embodiment does 
not physically prepare these doses for delivery, automated 
medication management system 3 00 completes pre- 

20 administration , verifications and checks and then prompts 
the user to administer the dose. The instrument then 
prompts the user to enter the actual dosage delivered, the 
time of delivery, and any other information pertinent to 
the delivery which may be useful in a data record. The 

25 user may also enter a notation from a predefined list of 
possible notes. In the case of a non- automated medication 
management system 300 administered IV, automated 
medication management system 3 00 can establish a record 
for that particular medication as well. 

3 0 At a later time the user can complete these records 

by entry into one of the instruments menu selections. In 
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this manner a record can be created for all meds delivered 
via automated medication management system 3 00 or external 
to the automated medication management system 300. The 
instrument can transmit that record to the various 
5 information systems within the health care facility, 
including, for example, the pharmacy; the admissions, 
discharges and transfers database, also known as the ADT; 
the billing information system; or other entity. The 
capability of creating an electronic Medication 
10 Administration Record (MAR) and other useful reports is 
another key capability. The instrument acts as a data 
collection point successfully acquiring all the 
information, at the patient's bedside, necessary to create 
those reports. 

15 Figure 29 is a flowchart illustrating a process 

relating to a door open request. Sensors exist on each of 
the two fluid delivery module doors, the outer and the 
inner door. If the outer door is opened, the instrument 
displays a message to the clinician of the consequences of 

20 proceeding. If the user does not want to continue opening 
the door, they could close the outer door and continue 
normal operations. If they do continue and open the inner 
door the cassette may be compromised and rendered 
unusable. As discussed previously, this is a safety 

25 feature of the device. When a new cassette is loaded, the 
instrument senses when the doors are closed, test to 
verify proper closure, and check if the cassette has been 
previously compromised. 

Figure 30 is a flowchart describing the operation of 

3 0 the Hold/Run button according to one embodiment of the 
invention. The Hold button is typically a timed function 
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enabling the instrument to be put on hold, stop all fluid 
delivery operations, at any time during its operation, 
subject to a typical five minute limitation before it will 
alarm that the instrument has been on hold too long. The 
5 Hold button can be used to silence an alarm condition. By 
pressing Hold the instrument is placed into a standby mode 
and the user has a period of time (five minutes in one 
embodiment) to fix the alarm condition. If the problem is 
unresolved, the instrument resumes the alarm indicating 

10 the hold period has expired. This is a safety feature to 
ensure that solutions continue to move to the patient and 
alarms are resolved quickly. 

Another feature of the system related to the Hold 
button is the operation of the Standby button. If the 

15 instrument were powered down, there may be no visibility 
as to whether the cassette doors were opened or closed or 
vial attachment mechanisms were actuated. By 
incorporating a standby command, along with the power 
command, on the keypad, the user is offered a choice of 

20 the condition. The default is standby for the instrument, 
but the user can use the cursor to move down to a power 
down command and press "OK." If the power down command is 
chosen, the instrument informs the user of the 
consequences, such as, for example, loss of the cassette, 

25 loss of patient information or loss of the network 
connection. Upon power up, parameters may need to be re- 
set, including for example patient ID, clinician ID, and 
so on. Standby mode maintains all the sensors on the 
doors and all the vial attachment mechanisms to notify 

3 0 users if there were any tampering going on the system 
would provide warnings and alarms to maintain the system's 
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integrity. The patient's ID is maintained in the standby 
mode and upon recovery needs to be verified. If there are 
any drugs previously scheduled on this instrument, the 
instrument examines the schedule, the current time, and 
5 asks the user to help resolve any issues by asking them to 
either reschedule drugs, to confirm drug deliveries, etc. 

In this document, the term database is generally used 
to refer to one or more data records or a collection of 
data regarding various types of information or data. This 

10 reference, along with any references to specific databases 
described herein are not intended to require a particular 
structure or organization of physical or logical 
databases. As would be apparent to one of ordinary skill 
in the art after reading this document, varying physical 

15 or logical data groupings can be provided in one or more 
locations or on one or more devices to implement the 
described databases. 

While the embodiments and applications of this 
invention have been shown and described, and while the 

20 best mode contemplated at the present time by the 
inventors has been described, it should be apparent to 
those skilled in the art that many more modifications are 
possible, without departing from the inventive concepts 
therein. Both product and process claims have been 

25 included and in the process claims it is understood that 
the sequence of some of the claims can vary and still be 
within the scope of this invention. The invention 
therefore can be expanded, and is not to be restricted 
except as defined in the appended claims and reasonable 

3 0 equivalence departing therefrom. 
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Claims 

1. A hand-held portable physician order entry- 
terminal for handling prescription information for one or 
more patients, comprising: 
5 data entry means for entering a patient 

identification, prescription information regarding a 
medication prescribed for said patient, and an 
identification of a physician prescribing said medication 
for said patient; 
10 means for checking said prescription information 

against patient information and medication information to 
determine whether it is appropriate to administer said 
medication to said patient; 

wherein said patient information comprises a 
15 condition of said patient, patient demographic 

information and patient allergies, and 

wherein said medication information comprises 
recommended dosage level, recommended dosing 
interval, drug interaction precautions, and side- 
20 effects for said medication; 

means for alerting a user when it is determined that 
it is not . appropriate to administer said prescribed 
medication to said patient. 


25 2. The hand-held portable physician order entry 

terminal of claim 1, further comprising means for 
electronically forwarding said prescription information to 
a pharmacy for filling said prescription. 

30 3. The hand-held portable physician order entry 

terminal of claim 2 , further comprising means for 
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inhibiting the forwarding of said prescription to said 
pharmacy when it is determined that it is not appropriate 
to administer said prescribed medication to said patient. 

5 4. The hand-held portable physician order entry 

terminal of claim 3, further comprising means for allowing 
said physician to override said means for inhibiting. 

5. A physician order system, comprising: 

10 means for entering a physician order, said physician 

order identifying a prescription of medication to be 
administered to a patient; 

means for electronically providing said physician 
order to a pharmacy, whereby said pharmacy uses said 
15 physician order to fill said prescription; and 

means for determining the propriety of administering 
said medication prescribed by said prescription. 

6. The physician order system of claim 5, further 
2 0 comprising means for alerting a user where it is 

inappropriate to administer said medication prescribed by 
said prescription. 

7. The physician order system of claim 5, further 
25 comprising means for entering patient data. 

8. The physician order system of claim 5, wherein 
said prescription information further comprises dosage and 
dosage interval information of said prescribed medication. 

30 
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9. The physician order system of claim 5, wherein 
said means for entering prescription information comprises 
a data entry terminal. 

5 10. The physician order system of claim 9, wherein 

said data entry terminal further comprises a tethered code 
reading device . 

11. The physician order system of claim 9, wherein 
10 said data entry terminal is a portable data entry 

terminal . 

12. The physician order system of claim 11, wherein 
said portable data entry terminal comprises : 

15 means for storing entered data; and 

means for downloading said stored entered data to 
said pharmacy. 

13. The physician order system of claim 12, wherein 
2 0 said means for downloading said stored entered data 

comprises at least one of the group of an RS-232 port, an 
network interface, an optical interface, a hardwired 
communication interface, and a wireless communication 
interface. 

25 

14. The physician order system of claim 11, wherein 
said portable data entry terminal further comprises an 
integrated code reading device. 

30 15. The physician order system of claim 9, wherein 

said means for determining the propriety of administering 
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said medication is and said means for alerting a user are 
integrated within said portable data entry terminal. 

16. The physician order system of claim 9, wherein 
5 said means for determining the propriety of administering 

said medication is located at a location remote from said 
portable data entry terminal and said means for 
downloading said entered data comprises means for 
downloading said entered data to said remote location. 

10 

17. The physician order system of claim 9, wherein 
said means for determining the propriety of administering 
said medication is located at said pharmacy and said means 
for downloading said entered data comprises means for 

15 downloading said entered data to said pharmacy. 

18. The physician order system of claim 5, wherein 
said data entry device further comprises means for 
entering an identification of a health- care provider. 

20 

19. The physician order system according to claim 5, 
wherein said means for determining the propriety of 
administering said medication prescribed by said 
prescription comprises means for checking said prescribed 

25 medication against information contained in one or more 
databases to determine whether it is appropriate to 
administer said prescribed medication to said patient. 

20. The physician order system according to claim 
3 0 19, wherein said means for checking said prescribed 

medication against information contained in one or more 
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databases comprises means for determining whether any 
patient information in a patient database indicates a 
conflict with said prescribed medication . 

5 21. The physician order system according to claim 

20, wherein said patient information in a patient database 
comprises at least one of the group of patient allergies 
medication, patient conditions, patient gender and other 
medication given to or prescribed for the patient. 

10 

22 . The physician order system according to claim 
19, wherein said means for checking said prescribed 
medication against one or more databases comprises means 
for comparing prescription parameters against parametric 

15 limits for said medication. 

23 . The physician order system according to claim 
22, wherein said prescription parameters comprise at least 
one of the group of dose, dosing interval, reconstitution 

20 level, diluent, and dilution amount. 

24 . The physician order system according to claim 
19, wherein said means for checking said prescribed 
medication against one or more databases further comprises 

25 means for determining whether prescription parameters' for 
said prescribed medication are within an acceptable range 
for a condition of said patient. 

25. The physician order system according to claim 6, 
30 wherein said means for alerting provides an alert to the 

user in near-real time. 
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26. The physician order system according to claim 5, 
wherein said means for alerting provides an alert to the 
user before said prescription information is provided to 
said pharmacy. 

5 

27. The physician order system according to claim 5, 
further comprising means for inhibiting the delivery of 
said prescription information to said pharmacy where it is 
inappropriate to administer said medication. 

10 

28. The physician order system according to claim 
27, further comprising means for overriding said means for 
inhibiting the delivery of said prescription information 
to said pharmacy. 

15 

29. The physician order system according to claim 
20, wherein said means for overriding comprises means for 
determining an access level of said user and selectively 
allowing said user to override said means for inhibiting 

20 based on said access level of said user. 

30. The physician order system according to claim 5, 
further comprising a communications interface. 

25 31. The physician order system according to claim 

11, wherein said data entry device further comprises means 
for entering a password identification of said clinician. 

32. A portable physician order entry terminal, 
3 0 comprising: 
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means for entering prescription information, said 
prescription information comprising information pertaining 
to a medication prescribed for a patient; 

means for checking said prescribed medication against 
5 stored data; and 

means for determining whether it is appropriate to 
administer said prescribed medication to said patient 
based on said stored data. 

33 . The portable physician order entry terminal of 
claim 32, further comprising means for alerting a user 
when said means for determining determines that it is not 
appropriate to administer said prescribed medication to 
said patient . 

34 . The portable physician order entry terminal of 
claim 32, further comprising: 

means for storing said stored data within said 
portable physician order entry terminal; and 

means for alerting a user upon entry of said 
prescription when said means for determining determines 
that it is not appropriate to administer said prescribed 
medication to said patient. 

25 35. The portable physician order entry terminal of 

claim 32, wherein said stored data is at a location remote 
from said portable physician order entry terminal and said 
means for checking said prescribed medication against 
stored data comprises means for retrieving data from said 

3 0 remote location to perform said checking. 
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36. The portable physician order entry terminal of 
claim 32, wherein said stored data is at a location remote 
from said portable physician order entry terminal, said 
means for checking said prescribed medication against 

5 stored data comprises means for forwarding said 
prescription information to said remote location to 
perform said checking at said remote location, and said 
means for determining comprises means for receiving an 
indication from said remote location as to whether it is 
.10 appropriate to administer said prescribed medication to 
said patient. 

37. The portable physician order entry terminal of 
claim 32, further comprising means for entering patient 

15 information . 

38. The portable physician order entry terminal of 
claim 37, wherein said patient information comprises an 
identification of a patient for whom medication is being 

20 prescribed. 

39. The portable physician order entry terminal of 
claim 37, wherein said patient information comprises 
patient demographic information, patient attributes, 

25 patient condition, other medication prescribed for 
patient, other medication patient is taking, and patient 
allergies . 

40. The portable physician order entry terminal of 
3 0 claim 39, wherein said patient demographic information 
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comprises at least one of the group of patient age, 
weight, height, and sex. 

41. The portable physician order entry terminal of 
5 claim 39, wherein said patient attributes comprise at 

least one of the group of patient's blood pressure, heart 
rate, body temperature. 

42. The portable physician order entry terminal 
0 according to claim 39, wherein said means for checking 

said prescribed medication comprises means for checking 
patient information to determine whether said patient is 
allergic to said prescribed medication. 

5 43. The portable physician order entry terminal 

according to claim 39, wherein said means for checking 
comprises means for checking patient information to 
determine whether said patient suffers from a condition 
which would be aggravated by said prescribed medication. 

0 

44. The portable physician order entry terminal 
according to claim 39, wherein said means for checking 
comprises means for checking patient information to 
determine whether said patient is on another medication 

5 which is incompatible with said prescribed medication. 

45. The portable physician order entry terminal 
according to claim 32, wherein said means for checking 
comprises means for comparing a prescribed dosage level of 

0 said prescribed medication against parametric parameters 
for said prescribed medication. 
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46. The portable physician order entry terminal 
according to claim 45, wherein said parametric parameters 
for said prescribed medication comprise at least one of 
the group of dosage level, dosing level, dilution amount, 

5 and administration rate. 

47. The portable physician order entry terminal 
according to claim 46, wherein said parametric parameters 
are determined based on patient information. 

10 

48. The portable physician order entry terminal 
according to claim 32, further comprising means for 
entering an identification of a health-care provider 
prescribing said medication to be administered to said 

15 patient. 

49. The portable physician order entry terminal 
according to claim 48, wherein said data entry device 
further comprises means for entering a password 

20 identification of said clinician. 

50. The portable physician order entry terminal 
according to claim 32, further comprising display means 
for providing visual information to a user. 

25 

51. The portable physician order entry terminal 
according to claim 32, further comprising means for 
forwarding said prescription information to a pharmacy. 


30 


52 . The portable physician order entry terminal 
according to claim 51, further comprising means for 
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inhibiting the forwarding of said prescription information 
to said pharmacy when it is determined that it is not 
appropriate to administer said prescribed medication to 
said patient. 

5 

53 . The portable physician order entry terminal 
according to claim 52, further comprising means for 
overriding said means for inhibiting the forwarding of 
said prescription information to said pharmacy. 

10 

54. The portable physician order entry terminal 
according to claim 53, wherein said means for overriding 
comprises means for determining an access level -of a user 
and selectively allowing said user to override said means 

15 for inhibiting the forwarding of said prescription 
information based on said access level . 

55. The portable physician order entry terminal 
according to claim 32, further comprising a communications 

20 interface. 

56. The portable physician order entry terminal 
according to claim 32, further comprising means for 
maintaining a record of medications prescribed to one or 

25 more patients. 

57. The portable physician order entry terminal 
according to claim 51, further comprising means for 
annotating the prescription information to indicate a 

30 precaution when it . is determined that it is not 
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appropriate to administer said prescribed medication to 
said patient. 

58. The portable physician order entry terminal 
5 according to claim 32, further comprising a printer for 

printing prescription information and patient information. 

59. The portable physician order entry terminal 
according to claim 39, wherein said patient demographic 

10 information comprises lab test values. 

60. The portable physician order entry terminal 
according to claim 32, wherein said means for checking 
comprises means for determining whether one or more 

15 medications have already been prescribed for the patient's 
condition to provide duplicate therapy checking. 

61. A physician order entry terminal, comprising 
a keypad for entering a prescription of medication 

for a patient; 

a software routine for receiving said prescription 
and validating said prescription against stored 
information to determine the propriety of said 
prescription for said patient; 

a display screen for displaying information regarding 
the entered prescription and the results of said 
validation performed by said software routine. 

62. The physician order entry terminal of claim 54, 
3 0 further comprising a communications interface for 

downloading said prescription to a remote location. 
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63. The physician order entry terminal of claim 54, 
further comprising: 

a power supply, and a processor, and a portable case 
for housing said keypad, software and display screen. 

5 

64 . A method for handling physician orders for 
prescription information for one or more patients, 
comprising the steps of: 

receiving a patient identification, prescription 
10 information regarding a medication prescribed for said 
patient, and an identification of a physician prescribing 
said. medication for said patient ; 

checking said prescription information against 
patient information and medication information to 
15 determine whether it is appropriate to administer said 
medication to said patient; 

wherein said patient information comprises a 
condition of said patient, patient demographic 
information and patient allergies, and 
20 wherein said medication information comprises 

recommended dosage level, recommended dosing 
interval, drug interaction precautions, and side- 
effects for said medication; 

alerting a user when it is determined that it is not 
25 appropriate to administer said prescribed medication to 
said patient. 

65. The method of claim 64, further comprising a 
step of electronically forwarding said prescription 

3 0 information to a pharmacy for filling said prescription. 
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66. The method of claim 65, further comprising a 
step of inhibiting the forwarding of said prescription to 
said pharmacy when it is determined that it is not 
appropriate to administer said prescribed medication to 

5 said patient . 

67. The method of claim 66, further comprising a 
step of allowing said physician to override the inhibited 
process . 
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